sdg-agents 1.0.5

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/03-delivery/01-ci-cd-pipeline.md

@@ -0,0 +1,49 @@
+# 01 - CI/CD Pipeline
+
+## Deploy Flow
+
+- What are the pipeline steps? (e.g., `LINT -> TEST -> BUILD -> DEPLOY`)
+- What tool do we use? (e.g., GitHub Actions, GitLab CI)
+
+## Approval Requirements (PR)
+
+- [ ] Linter without errors.
+- [ ] Tests passing.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 01 - CI/CD Pipeline
+
+## Deploy Flow
+
+Git Push and Docker.
+
+## Approval Requirements
+
+Whoever the creator wants.
+```
+
+> **Rationale**: "Git Push" is not a pipeline. "Whoever the creator wants" invalidates technical governance.
+
+### ✅ Good Example
+
+```markdown
+# 01 - CI/CD Pipeline
+
+## Deploy Flow
+
+GitHub Actions: `LINT` -> `UNIT-TEST` -> `SAST` -> `DOCKER-BUILD` -> `AWS-DEPLOY`.
+
+## Approval Requirements
+
+- [x] Linter passing.
+- [x] 100% of unit tests green.
+- [x] 0 critical vulnerabilities in SonarQube.
+```
+
+> **Rationale**: Defines technologies (GitHub Actions, SonarQube), clear steps, and rigid requirements for the PR.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/03-delivery/02-quality-standards.md

@@ -0,0 +1,46 @@
+# 02 - Quality Standards
+
+## What Does Quality Mean to Us?
+
+- Code without obvious technical debt.
+- Tests that actually test business rules.
+
+## Minimum Coverage
+
+- [e.g., 80% in business logic]
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 02 - Quality Standards
+
+## What is Quality
+
+Having few bugs and pretty code.
+
+## Minimum Coverage
+
+10%.
+```
+
+> **Rationale**: "Few bugs" and "pretty" are subjective. 10% coverage is insignificant and dangerous.
+
+### ✅ Good Example
+
+```markdown
+# 02 - Quality Standards
+
+## What is Quality
+
+Code that follows SOLID principles and 100% of critical payment flows with E2E test coverage.
+
+## Minimum Coverage
+
+80% line coverage in `/internal/domain`.
+```
+
+> **Rationale**: Defines concrete principles (SOLID) and aggressive testing goals for critical areas.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/03-delivery/03-delivery-approval.md

@@ -0,0 +1,58 @@
+# 03 - Delivery Approval
+
+## Artifacts Checklist
+
+- [ ] 01-ci-cd-pipeline.md (Running)
+- [ ] 02-quality-standards.md (Approved)
+
+## Operational Approval
+
+- **SRE / DevOps**: [Signature/Date]
+- **Tech Lead**: [Signature/Date]
+
+## Definition of Readiness (Ready for Features)
+
+- [ ] Automated CI/CD pipeline up to Staging.
+- [ ] Linter and Unit Tests block PRs.
+- [ ] Basic monitoring (Logs/Metrics) active.
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 03 - Delivery Approval
+
+## Checklist
+
+- [x] The pipeline works.
+
+## Definition of Readiness
+
+- [x] Ready to code.
+```
+
+> **Rationale**: "Works" is vague. Where is the automatic Staging deploy log?
+
+### ✅ Good Example
+
+```markdown
+# 03 - Delivery Approval
+
+## Checklist
+
+- [x] 01-ci-cd-pipeline.md (GitHub Actions Active)
+
+## Operational Approval
+
+- **SRE / DevOps**: Lana Lime (2026-05-30)
+
+## Definition of Readiness
+
+- [x] PR blocking configured in GitHub for Lint/Test failures.
+- [x] Grafana "Health" Dashboard created in Staging.
+```
+
+> **Rationale**: Defines real operational criteria such as PR blocking and active monitoring.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/04-features/00-feature-template.md

@@ -0,0 +1,30 @@
+# [ID]- [Feature Name]
+
+## Context
+
+- Problem to be solved.
+- Expected business or system impact.
+
+## Scope
+
+- Planned deliverables.
+- What will NOT be covered (Non-goals).
+
+## Business Rules
+
+- Critical validations.
+- Success and exception flowcharts.
+
+## Architecture & Design
+
+- Integration point with the current system.
+- Definition of new contracts (API) or schema changes (DB).
+
+## Implementation Roadmap
+
+1. [ ] Task 1
+2. [ ] Task 2
+
+## Testing Strategy
+
+- Validation scenarios (A, B, C).

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/04-features/01-context-and-scope.md

@@ -0,0 +1,46 @@
+# 01 - Context and Scope (Context & Scope)
+
+## Problem and Impact (What and Why)
+
+- **Business Problem:** Which customer or operational "pain point" are we solving?
+- **Affected Metrics:** What do we expect to improve? (e.g., +Conversion, -Response Time, +Retention).
+- **Target Audience:** Does it affect all users, admins, or just a specific role?
+
+## Scope (Scope Boundaries)
+
+- **In-Scope (Goals):** What **MUST** be delivered as part of this feature.
+- **Out-of-Scope (Non-Goals):** What we **WILL NOT** do now (fundamental to protect against _Scope Creep_).
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# Context
+
+We need to add an export to PDF button.
+
+# Scope
+
+Make the export work.
+```
+
+> **Rationale**: Does not say "Why". Exporting to PDF is the solution, not the problem. What if the problem is "the accountant needs the monthly report"? Perhaps a CSV silently sent by email would be better than a slow button on the UI.
+
+### ✅ Good Example
+
+```markdown
+# Context
+
+**Problem:** Currently, our shopkeepers spend 4 hours a month taking screenshots of sales screens to send to accounting.
+**Metrics:** Reduce time spent by shopkeepers (CSAT) and decrease CS tickets asking for reports.
+
+# Scope
+
+**In-Scope:** UI-based export of CSV and PDF reports from the "Financial" tab.
+**Out-of-Scope:** Automatic scheduling (Cron) of report delivery. We will only perform manual exports for now.
+```
+
+> **Rationale**: Defines the root problem and blocks inappropriate future proposals for the moment (such as automatic scheduling) that would delay delivery.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/04-features/02-business-rules.md

@@ -0,0 +1,39 @@
+# 02 - Business Rules
+
+## Logic and Behavior
+
+- **Main Flow (Happy Path):** What is the ideal path for the entity or user? (Use Clear User Stories or Flowcharts).
+- **Domain Constraints:** Logical limits of the application. (e.g., "An order cannot move from 'Shipped' back to 'Pending'").
+
+## Edge Cases & Validations (Sad Path)
+
+- **Edge Scenarios:** What happens when parameters are invalid? (e.g., "Age < 18 on a blocked purchase").
+- **Concurrency (Race Conditions):** What if 2 users access the same resource simultaneously? (e.g., buying the last ticket).
+- **Partial Resilience:** If something external fails, do we block everything or offer a fallback?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# Rules
+
+- The user submits the form and it's saved in the 'tbl_users' database.
+- If it fails, return 500.
+```
+
+> **Rationale**: It's coupled to the database and technical errors (500). Business rules should be described in a technology-agnostic way, focusing on _behavior_ rather than _implementation_.
+
+### ✅ Good Example
+
+```markdown
+# Rules
+
+- **Happy Path:** The shopkeeper creates a Coupon and defines its validity. The system allows its use on listed products.
+- **Constraints:** The coupon discount value can never be greater than the price of the lowest-priced item in the cart (To avoid negative order balances).
+- **Concurrency (Race Condition):** A coupon with `use_limit = 1` must use Optimistic Locking; if two users attempt checkout in the same millisecond, one will receive a "Coupon Exhausted" error.
+```
+
+> **Rationale**: The developer will read this and IMMEDIATELY remember to shield the entity against "negative values" and apply a database lock when debiting the coupon.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/04-features/03-architecture-and-design.md

@@ -0,0 +1,50 @@
+# 03 - Architecture and Technical Design (Architecture & Design)
+
+## API-First (Contracts and Envelopes)
+
+- **Exposed Endpoints:** Routes, Verbs (GET/POST/PUT/PATCH/DELETE), or gRPC methods.
+- **Request Payload:** Expected input format.
+- **Response Schemas (Envelopes):** The unified success format and, crucially, the unified standard for **Business Error** or Validation messages.
+
+## Data Modeling (Data Models / Persistence)
+
+- **Entities and Relationships:** Which tables/collections should be created/altered? (ER Diagram or Mermaid).
+- **Migration Strategy:** Will we need to migrate data from legacy or just insert columns (Add-only)? What about indexes for read queries?
+
+## External Integrations (Third-parties)
+
+- **Suppliers/Vendors:** Does the feature call AWS S3, Stripe, Slack, etc.?
+- **Rate Limits & Fallback:** How does the feature handle the failure of this third-party API?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# API and DB
+
+Create a POST /upload route.
+Save the PDF in the Docs table.
+```
+
+> **Rationale**: Vague and subject to free interpretation (every Dev will do it differently). It doesn't show possible HTTP statuses or where the actual large binaries will live.
+
+### ✅ Good Example
+
+```markdown
+# Contracts (API-First)
+
+- **POST** `/api/v1/workspaces/{id}/reports`
+- **Expected HTTP Statuses:** `201 Created` (Success), `422 Unprocessable` (Validation), `404 Not Found` (Non-existent Workspace).
+- **Response Envelope:** The `422` error must follow [RFC 7807](https://datatracker.ietf.org/doc/html/rfc7807) (Problem Details).
+
+# Data Modeling
+
+- **Relational Table:** `reports (id, type, target_month, status, file_url)`.
+- **Constraint:** `UNIQUE (workspace_id, target_month)` to avoid duplicate report generation.
+- **Storage:** The physical file (.pdf) will be streamed directly to an S3 Bucket (Never store Blobs in a relational database).
+```
+
+> **Rationale**: Puts an end to endless PR discussions. The Front-End Dev knows exactly what payload to expect (even if the backend hasn't coded anything yet). The DBA understands the indexes that will be generated.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/04-features/04-testing-strategy.md

@@ -0,0 +1,48 @@
+# 04 - Testing Strategy (Testing Strategy)
+
+## TDD / BDD Approach
+
+- Which key behaviors described in the `02-business-rules.md` file must be covered by **Unit Tests**? (e.g., Testing the exception thrown when weight is negative).
+- Which routes described in the `03-architecture-and-design.md` file will require **Integration Tests** simulating real requests using Mocks/Stubs for the Database/External Dependencies?
+
+## Extreme Cases (Smoke & Performance)
+
+- Does the feature involve heavy data? Will a load testing script (K6, JMeter) be necessary?
+- How to validate if integrations with third-party applications fail gracefully (e.g., banking API timeout)?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# Strategy
+
+Create tests with Jest/XUnit.
+Run in the CI.
+```
+
+> **Rationale**: Too generic. Every squad will run tests in the CI, but WHAT needs to be tested so that we can validate even before the first "If" is programmed?
+
+### ✅ Good Example
+
+```markdown
+# Testing Strategy
+
+**Unit (Unit Tests - Domain Focus)**
+Should focus on the `CouponDomain` Entity:
+
+- `(Happy Path)` If valid, discounts value.
+- `(Sad Path)` Throws `InsufficientBalanceException`.
+- `(Sad Path)` Throws `ExpiredCouponException` if CurrentDate > Validity.
+
+**Integration (Controller/API Focus)**
+
+- Mock external payment API to always return "Approved".
+- Execute POST /checkout request and ensure that:
+  - The `tbl_orders` table inserted a new ID.
+  - Final return `201 Created` and body contains `{ success: true, order_id: 12 }`.
+```
+
+> **Rationale**: Based on this _Strategy_, even more junior devs build efficient `.spec.ts` files without being afraid of the PR being blocked or leaving security holes or domain failures.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/04-features/05-implementation-plan.md

@@ -0,0 +1,45 @@
+# 05 - Implementation Plan (Implementation Plan)
+
+## Execution Checklist
+
+- **Dependent Stages:** Which steps must necessarily come before another? (e.g., Database Migrations **before** Use Cases, and Use Cases **before** HTTP/gRPC APIs).
+- **Parallelized Deliveries:** Can the frontend be executed in parallel based on the `03-architecture` document (API-First contracts)? Which Jira IDs and tasks accompany it?
+
+## Rollout, Fallback & Observability
+
+- How are we going to launch in production? In percentages (Canary Config) or via **Feature Flags** (Dark Launch)?
+- **Fallback Plan:** How to undo this instantly without downtime? And which logs (Datadog/ELK) will trigger the alert if the 500 Error level spikes?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# Execution
+
+1. Do database, 2. Do Backend, 3. Do Frontend, 4. Deploy Friday.
+```
+
+> **Rationale**: Trivial and lacks managerial visibility or structured tactics. Besides being incredibly susceptible to "Merge conflicts" in a large team, it generates panic if an error occurs (no Rollback!).
+
+### ✅ Good Example
+
+```markdown
+# Checklist (Implementation Stages)
+
+- `[FRONT]` Issue #212: Mock base form based on the `/api/v2/products` contract.
+- `[BACK]` Issue #213: Create PR with `Flyway Migration` `.sql`: adding the "tags" table (Add-only).
+- `[BACK]` Issue #214: Implement DB interface repositories.
+- `[BACK]` Issue #215: Connect Controller to UseCases.
+- `[INTEGRATION]`: Connect UI to already existing endpoints in Staging.
+
+# Operational Strategy
+
+- All endpoints and new UI components will be protected behind the Feature Flag `FEATURE_ENABLE_PRODUCT_TAGS=false`.
+- We will enable only for _Internal Users_ (Admins).
+- We will increase to 25% of the base. If Datadog points to a P95 latency error > 1s, the dashboard itself inverts the Flag (Automatic Instant Fallback). No need for a new Deploy to rollback the code.
+```
+
+> **Rationale**: Brings extreme confidence in CD (Continuous Delivery). The million-dollar feature is "live" in the code, but selectively enabled and with 1-second Fallbacks.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/04-features/06-feature-approval.md

@@ -0,0 +1,46 @@
+# 06 - Readiness (Feature Approval Check)
+
+## Definition of Done (DoD)
+
+- This artifact should act as the final release Gatekeeper before the PR (Pull Request) goes to Master/Main.
+- Revisit the 5 previous template files before "signing off" on the delivery of this Feature.
+
+## Sign-offs (Mutual Approval)
+
+- **Product Manager**: [Signature/Date]
+- **Tech Lead**: [Signature/Date]
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# Approval
+
+- Tests run on Master. Everything is ok.
+- Someone looked at the PR and gave LGTM.
+```
+
+> **Rationale**: Passive and loose validation. The process needs checklists that enforce the technical QA of the architecture that the **Spec-Driven Kit** imposed.
+
+### ✅ Good Example
+
+```markdown
+# Feature Gatekeeper / Checklist
+
+- [x] Context and Scope (Is Document `01` clear and in-scope respected)?
+- [x] All User Stories mapped in Doc `02` are in the E2E/Unit Tests?
+- [x] Was the API-First Contract and Model/Migrations (Doc `03`) strictly followed? (If any route changes occurred, were dependent teams informed?)
+- [x] Are all exception cases from Document `04` Asserted in the CI Pipeline?
+- [x] Rollback / Feature-Flags implemented according to Doc `05`? No hardcoded connections?
+
+# Sign-offs / Hand-offs
+
+- **Product Owner:** PM reviewed final interface in `Staging` (Julia Silver - 2026-04-21).
+- **Tech Lead:** Code Security review and SonarQube green without critical `Code Smells` (Robert Coast - 2026-04-22).
+- **Status:** APPROVED. 🚀 Ready to enable the flag on the `Main` branch.
+```
+
+> **Rationale**: Ensures organizational discipline; all submitted code faithfully reflects the initial feature planning. The team understands dependencies and ties together Testing, Rollback, and Behavior threads from end to end.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/05-evolution/01-rfcs-and-changes.md

@@ -0,0 +1,63 @@
+# 01 - Request for Comments (RFC) & Architecture Changes
+
+## Problem and Motivation for Change
+
+- What motivated the evolution of this architecture in an already live system (e.g., performance bottleneck in the relational database forcing the use of NoSQL, or a Cloud Provider change)?
+- What is the impact of _Doing Nothing_ (Status Quo) compared to the effort of the change?
+
+## Alternatives Considered
+
+- What were "Paths B and C" that the team rejected before proposing "Path A"?
+- Why is the chosen option the most suitable today (Cost x Return)?
+
+## Execution and Rollback Plan
+
+- How will the current code base be migrated to the new foundation without _Downtime_?
+- What is the acceptable error threshold to abort the change and revert to the previous state?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 01 - RFC: Change Database
+
+## Motivation
+
+MongoDB is slow.
+
+## Alternatives
+
+PostgreSQL is better.
+
+## Execution
+
+We'll do a script on Saturday.
+```
+
+> **Rationale**: RFC with zero scientific basis. It disregards that there is no "silver bullet" and attempts to inflict a radical change on the structure without analyzing the cost of data migration and _downtime_.
+
+### ✅ Good Example
+
+```markdown
+# 01 - RFC: Decouple Notification Module to Messaging (RabbitMQ)
+
+## Motivation
+
+**Problem**: Current synchronous Email requests via API cause _Timeouts_ (5s) during peak hours (Black Friday), freezing Main App threads.
+
+## Alternatives Considered
+
+1. **Pay for larger instances (Scale Up)**: Rejected for not being financially scalable in the long term.
+2. **AWS SQS (Serverless)**: Rejected because the budget is locked and we already have an idle bare-metal server in the infra.
+3. **RabbitMQ (Chosen)**: Ensures asynchronicity with zero license cost.
+
+## Execution
+
+- **Shadow**: In the 1st week, RabbitMQ will be enabled but will publish invisible logs while the synchronous code remains active, just to check data consistency.
+- **Rollback**: If `AckRate < 99.9%`, we flip the `UseAsyncNotifications` _Feature Flag_ to `false` in the remote dashboard in real-time, without the need for a _Deploy_.
+```
+
+> **Rationale**: Mature approach, evaluating financial costs and ensuring that the plan does not cause panic for product managers by having real-time security _Feature Flags_.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/05-evolution/02-incident-postmortems.md

@@ -0,0 +1,64 @@
+# 02 - Incident Post-Mortems (Outage Analysis)
+
+## Timeline and Impact
+
+- What was the exact timeline from the start of the systemic failure to full recovery (_Time to Recovery_)?
+- How many users or transactions were impacted by the downtime? Were there alerts covering this specific type of failure?
+
+## Root Cause Analysis ("The 5 Whys")
+
+- How did the system break? (Avoid pointing fingers at individuals _"Someone messed up"_; focus on the process _"The pipeline let it through"_).
+- What was the "hidden trigger" that didn't appear in the _Staging / Homogenization_ environment?
+
+## Action Plan (Action Items)
+
+- What does the team **need to implement** in the code, infrastructure, or CI/CD so that this failure **never** happens again structurally in the future?
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# 02 - Post-Mortem: Database Down
+
+## Impact
+
+It was bad in the afternoon, and customers complained.
+
+## Root Cause
+
+John ran the wrong migration command in production.
+
+## Action Items
+
+John will be more careful and take a SQL course.
+```
+
+> **Rationale**: Classic blame culture. Condemning the developer does not resolve systemic fragility. In 6 months, "Joseph" will run the wrong command again because the pipeline remains loose.
+
+### ✅ Good Example
+
+```markdown
+# 02 - Post-Mortem: Master Database Down (DB-Outage)
+
+## Timeline
+
+- `14:02 PM`: PostgreSQL CPU usage hits 100%.
+- `14:05 PM`: Gateway starts returning Status 504 in the App for ~4,500 connected users.
+- `14:14 PM`: Datadog alarm goes off in the Ops Slack. Escalation triggered.
+- `14:26 PM`: Manual rollback of the _Target Group_, restored to normality. Duration of **24 min**.
+
+## Root Cause Analysis
+
+1. **Why did the CPU explode?** N+1 query from a heavy report uploaded this morning.
+2. **Why did it pass the CI?** Lack of data volume metrics in the _Load Test_ pipeline.
+
+## Action Items
+
+- **[Tomorrow]**: Add a mandatory global pagination limit `limit(50)` in the Base API.
+- **[By Friday]**: Integrate `k6` into the CI with a cloned database at 10% volume, blocking any query `> 500ms`.
+```
+
+> **Rationale**: Professionalized the failure. Without a witch hunt, the failure becomes the genetic seed of automated protection in the company's future infrastructure.

package/src/assets/dev-guides/prompt-tracks/01-new-evolution/05-evolution/03-adr-template.md

@@ -0,0 +1,66 @@
+# 03 - Architecture Decision Record (ADR)
+
+This standard template must be used to document any and all structuring architectural decisions throughout the project's life. An ADR ensures that the historical context of the decision (Why didn't we use tool X?) will be preserved forever.
+
+## Context and Problem
+
+- **Status:** [Proposed | Accepted | Rejected | Obsolete]
+- **What is the current technical pain?** What motivated the team to seek a new architectural solution or insert a new heavy dependency?
+
+## Options Considered
+
+- Option 1: [Name and Brief Description] (Pros and Cons)
+- Option 2: [Name and Brief Description] (Pros and Cons)
+
+## Decision (What we will do)
+
+- Option X was chosen because [Rationale].
+
+## Consequences and Trade-offs
+
+- What do we lose with this decision? (e.g., +Cost, steeper learning curve).
+- What do we gain? (e.g., +Scalability, -Latency).
+
+---
+
+## Learn by Examples
+
+### ❌ Bad Example
+
+```markdown
+# ADR: Migrate to Postgres
+
+**Status:** Done
+We chose PostgreSQL because MySQL was slow and the CTO ordered it. We will gain speed.
+```
+
+> **Rationale**: Lacks metrics. "Was slow" is not a metric. What were the evaluated trade-offs? Which versions of PG vs. MySQL operated under stress? Anyone who inherits this in the future will not know the _real_ weight of the technical decision.
+
+### ✅ Good Example
+
+```markdown
+# ADR: Migrate RabbitMQ Queue to AWS SQS
+
+**Status:** Accepted
+
+## Context
+
+We have 1M jobs/day and the on-premise RabbitMQ cluster managed by us consumes 20h/month of DevOps just in patches and OOM (Out-of-memory) monitoring.
+
+## Options Considered
+
+- 1. **Paid RabbitMQ Cloud**: Cost $500/month. Preserves our existing code.
+- 2. **AWS SQS**: Estimated cost $8/month thanks to low throughput; requires rewriting the backend's IMessageQueue interface.
+
+## Decision
+
+Option 2 (SQS) was chosen due to unbeatable long-term cost margins and being fully serverless.
+
+## Consequences
+
+- Gains: Zero hours in infrastructure maintenance, cost reduced from $500 to $8.
+- Losses: Estimated 1-sprint refactor (~12 points) in the Backend to switch libraries.
+- Risk: Partial lock-in to the AWS cloud.
+```
+
+> **Rationale**: Perfect history. Someone 3 years in the future reads this document and perfectly understands the cost and operational pressures of the time. No one will debate and reignite the desire to return to RabbitMQ without a more solid argument.