tribunal-kit 2.4.6 → 3.1.0

package/.agent/skills/deployment-procedures/SKILL.md

@@ -1,188 +1,111 @@
 ---
 name: deployment-procedures
-description: Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.
+description: Production application deployment mastery. Zero-downtime deployment strategies (Blue/Green, Rolling updates), Container orchestration (Docker/ECS), CI/CD pipelines, secrets injection, database migration safety, health checks, and rollback contingencies. Use when moving code from development to production execution.
 allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-12
+version: 2.0.0
+last-updated: 2026-04-02
 applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
-# Deployment Principles
-
-> Deployments are not risky because of the code. They are risky because of all the
-> assumptions that have never been tested in production.
-
----
-
-## The Core Tension
-
-Speed vs. safety. Moving fast reduces iteration time. Moving carefully reduces incidents.
-The answer is not "always be careful" — it's **make fast safe**.
-
-That means:
-- Deployments that are reversible
-- Changes that are observable in real time
-- Failures that are isolated to a subset of users
-- State changes that can be undone without code changes
+# Deployment Procedures — Production Execution Mastery
 
 ---
 
-## Five Phases of Safe Deployment
-
-### Phase 1 — Pre-Flight
-
-Before touching anything in production:
-
-- [ ] Tests passing on the branch being deployed
-- [ ] No pending schema migrations that will break the current production code
-- [ ] Feature flags in place for any risky changes
-- [ ] Rollback plan confirmed — "delete the feature flag" is a valid plan, "redeploy" is not (too slow)
-- [ ] Team notified if deployment will cause visible disruption
-
-### Phase 2 — Database First
-
-If there are schema changes:
-
-- Deploy the migration **before** the code that depends on it
-- Verify the migration completed and the database is healthy
-- The new code must be backward-compatible with the old schema (for the window during which old pods are still running)
+## 1. Zero-Downtime Deployment Strategies
 
-**Never:**
-- Add NOT NULL without a DEFAULT in the migration
-- Drop a column in the same deployment that removes the code referencing it
-- Run a migration that locks the table for more than a few seconds without scheduling a maintenance window
+Stopping a server, pulling code, building, and restarting is unacceptable. This results in 30-120 seconds of 502 Bad Gateway errors.
 
-### Phase 3 — Code Deploy
-
-Deploy with traffic distribution:
-
-| Strategy | Risk | When to Use |
-|---|---|---|
-| Direct (all-at-once) | High | Small teams, low traffic, with immediate rollback |
-| Rolling | Medium | Multiple instances, gradual update, auto-rollback on health fail |
-| Blue/Green | Low | Mission-critical services, instant switch and rollback |
-| Canary | Very low | Unknown risk level, expose to 1–5% of traffic first |
-
-### Phase 4 — Verify
-
-After deploying, watch:
-
-- Error rate — compare to pre-deploy baseline, not zero
-- Response time P50, P95, P99 — not just average
-- Business metric if visible (conversion, checkout completion)
-- Key logs for new error patterns
-
-Wait at minimum:
-- 5 minutes for canary verification
-- 15 minutes for a rolling deploy
-- Until traffic covers the full daily pattern for any significant feature
-
-### Phase 5 — Complete or Roll Back
-
-**Roll back when:**
-- Error rate increases by more than 2x pre-deploy baseline
-- P95 latency increases significantly without an expected cause
-- A critical user path stops working
-
-**Complete when:**
-- All metrics stable for the required observation window
-- All instances updated
-- Feature flags cleaned up if used
-
----
+### Blue/Green Deployment
+- Two identical environments (Blue is live, Green is idle).
+- Deploy v2 to Green. Run smoke tests on Green.
+- Swap the reverse proxy (Nginx or Load Balancer) router from Blue to Green.
+- Zero downtime. Rollback is instant (swap router back to Blue).
 
-## Rollback vs. Roll Forward
+### Rolling Updates (Container Clusters)
+- If you have 5 containers running v1. 
+- Spin up 1 container running v2. Wait for it to pass health checks.
+- Drain and terminate 1 container of v1.
+- Repeat until all 5 containers run v2.
 
-| Scenario | Recommendation |
-|---|---|
-| Bug in new code, no data mutations | Roll back (redeploy previous version) |
-| Bug in new code, data already mutated | Roll forward (fix the mutation in a follow-up deploy) |
-| Schema migration caused the issue | Fix forward — migrations are rarely safely reversible |
-| Feature flag controls the issue | Turn off the flag — fastest rollback possible |
-
----
-
-## Environment Hierarchy
-
-Code flows one direction: dev → staging → production. Never skip staging for anything non-trivial.
-
-- **Development:** Fast iteration, local data, no external consequences
-- **Staging:** Production-like data (anonymized), used for final verification
-- **Production:** Real users, real consequences, thorough before touching
+```bash
+# Docker Swarm / ECS / Kubernetes inherently handle rolling updates
+docker service update --image myapp:v2 --update-parallelism 1 --update-delay 10s myapp_web
+```
 
 ---
 
-## What a Deployment Runbook Contains
-
-For any significant deployment, document before starting:
-
-```
-Date/Time:         
-Engineer:          
-What is changing:  
-Why:               
-Expected behavior: 
-How to verify:     
-Rollback plan:     
-Time to rollback:  
+## 2. Infrastructure as Code (IaC) CI Pipelines
+
+All deployment logic must be codified and checked in alongside the application code.
+
+```yaml
+# .github/workflows/deploy.yml
+name: Production Deploy
+
+on:
+  push:
+    branches: [ "main" ]
+
+# Concurrency limits prevent race conditions if two commits are pushed rapidly
+concurrency: 
+  group: production-deploy
+  cancel-in-progress: true
+
+jobs:
+  build_and_deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      
+      # 1. CI Phase: Fast fail
+      - name: Install & Audit
+        run: npm ci && npm audit --audit-level=high
+      
+      - name: Unit Tests
+        run: npm test
+
+      # 2. Build Phase
+      - name: Build Assets
+        run: npm run build
+
+      # 3. CD Phase (Deployment via SSH/Docker)
+      - name: Deploy to Server
+        uses: appleboy/ssh-action@master
+        with:
+          host: ${{ secrets.SERVER_HOST }}
+          username: deploy_user
+          key: ${{ secrets.DEPLOY_SSH_KEY }}
+          script: |
+            cd /opt/myapp
+            git pull origin main
+            docker-compose up -d --build
+            # Container starts in background, port mapped to Nginx.
 ```
 
 ---
 
-## Output Format
+## 3. Database Migration Safety Rules
 
-When this skill produces a recommendation or design decision, structure your output as:
-
-```
-━━━ Deployment Procedures Recommendation ━━━━━━━━━━━━━━━━
-Decision:    [what was chosen / proposed]
-Rationale:   [why — one concise line]
-Trade-offs:  [what is consciously accepted]
-Next action: [concrete next step for the user]
-─────────────────────────────────────────────────
-Pre-Flight:  ✅ All checks passed
-             or ❌ [blocking item that must be resolved first]
-```
+Schema changes cause 90% of severe deployment outages. 
 
+**The Expand-and-Contract Pattern (Zero Downtime DB Migrations):**
+Never drop columns or rename tables on a live system. Old code running against new schemas *will* crash.
 
+*Goal: Rename column `first_name` to `given_name`*
+- **Phase 1 (Expand):** Add `given_name` as a NEW, nullable column. The app writes to BOTH columns simultaneously, reads from `first_name`.
+- **Phase 2 (Migrate):** Run background script copying `first_name` data to `given_name`.
+- **Phase 3 (Swap):** Deploy v2 Application code that reads/writes exclusively to `given_name`.
+- **Phase 4 (Contract):** Drop the legacy `first_name` column weeks later.
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 4. The 5-Minute Rollback Guarantee
 
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+If the new deployment throws persistent 5xx errors, how fast can you revert?
+If the answer relies on "recompiling the old git commit," you have failed.
 
-1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
-2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
-3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
-4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
+1. **Docker Tags:** Every build is tagged with the Git SHA (`myapp:a1b2c3d`). Reverting is a split-second container swap.
+2. **Feature Flags:** The code deployed completely dormant. If it breaks when toggled via flag, the rollback is hitting the "Off" button on LaunchDarkly (Zero code deployed).
+3. **Database Integrity:** Migrations are explicitly atomic (`BEGIN; DROP TABLE...; COMMIT;`) so failures roll back seamlessly.
 
 ---
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-### ✅ Pre-Flight Self-Audit
-
-Review these questions before confirming output:
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.

package/.agent/skills/devops-engineer/SKILL.md

@@ -1,134 +1,295 @@
 ---
 name: devops-engineer
-description: Senior DevOps engineer with expertise in building scalable, automated infrastructure and deployment pipelines. Your focus spans CI/CD implementation, Infrastructure as Code, container orchestration, and monitoring.
+description: DevOps engineering mastery. Docker containerization, Docker Compose, CI/CD with GitHub Actions, Kubernetes basics, infrastructure as code (Terraform), monitoring/alerting, deployment strategies (blue/green, canary, rolling), secrets management, and production readiness checklists. Use when building CI/CD pipelines, containerizing apps, or managing infrastructure.
 allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-12
+version: 2.0.0
+last-updated: 2026-04-01
 applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
-# Devops Engineer - Claude Code Sub-Agent
-
-You are a senior DevOps engineer with expertise in building and maintaining scalable, automated infrastructure and deployment pipelines. Your focus spans the entire software delivery lifecycle with emphasis on automation, monitoring, security integration, and fostering collaboration between development and operations teams.
-
-## Configuration & Context Assessment
-When invoked:
-1. Query context manager for current infrastructure and development practices
-2. Review existing automation, deployment processes, and team workflows
-3. Analyze bottlenecks, manual processes, and collaboration gaps
-4. Implement solutions improving efficiency, reliability, and team productivity
+# DevOps Engineer — CI/CD & Infrastructure Mastery
 
 ---
 
-## The DevOps Excellence Checklist
-- Infrastructure automation 100% achieved
-- Deployment automation 100% implemented
-- Test automation > 80% coverage
-- Mean time to production < 1 day
-- Service availability > 99.9% maintained
-- Security scanning automated throughout
-- Documentation as code practiced
-- Team collaboration thriving
+## Docker
 
----
+### Dockerfile (Production-Ready)
 
-## Core Architecture Decision Framework
+```dockerfile
+# ✅ Multi-stage build — minimal final image
+FROM node:22-alpine AS builder
+WORKDIR /app
 
-### Infrastructure as Code & Orchestration
-*   **IaC Mastery:** Terraform modules, CloudFormation templates, Ansible playbooks, Pulumi.
-*   **State & Drift:** Configuration management, Version control, State management, Drift detection.
-*   **Containers:** Docker optimization, Kubernetes deployment, Helm chart creation, Service mesh setup.
+# Install deps first (cache layer)
+COPY package.json package-lock.json ./
+RUN npm ci --ignore-scripts
 
-### CI/CD Implementation & SecOps
-*   **CI/CD:** Pipeline design, Build optimization, Quality gates, Artifact management, Rollback procedures.
-*   **Security Integration:** DevSecOps practices, Vulnerability scanning, Compliance automation, Access management.
+# Build
+COPY . .
+RUN npm run build
 
-### Cloud Platform Expertise & Performance
-*   **Cloud Platforms:** AWS, Azure, GCP, Multi-cloud strategies, Cost optimization, Disaster recovery.
-*   **Performance:** Application profiling, Resource optimization, Load balancing, Auto-scaling.
-*   **Observability:** Metrics collection, Log aggregation, Distributed tracing, Alert management, SLI/SLO definition.
+# ──── Production stage ────
+FROM node:22-alpine AS runner
+WORKDIR /app
 
----
+# Security: non-root user
+RUN addgroup --system --gid 1001 appgroup && \
+    adduser --system --uid 1001 appuser
 
-## Output Format
+# Copy only production artifacts
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/node_modules ./node_modules
+COPY --from=builder /app/package.json ./
 
-When this skill produces a recommendation or design decision, structure your output as:
+USER appuser
+EXPOSE 3000
+ENV NODE_ENV=production
 
-```
-━━━ Devops Engineer Recommendation ━━━━━━━━━━━━━━━━
-Decision:    [what was chosen / proposed]
-Rationale:   [why — one concise line]
-Trade-offs:  [what is consciously accepted]
-Next action: [concrete next step for the user]
-─────────────────────────────────────────────────
-Pre-Flight:  ✅ All checks passed
-             or ❌ [blocking item that must be resolved first]
-```
+HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
+  CMD wget --quiet --tries=1 --spider http://localhost:3000/health || exit 1
 
+CMD ["node", "dist/index.js"]
+```
 
----
+```dockerfile
+# ❌ HALLUCINATION TRAP: Common Dockerfile mistakes
+# ❌ FROM node:22         ← 1GB+ image (use alpine: ~150MB)
+# ❌ RUN npm install      ← installs devDependencies, no lockfile
+# ✅ RUN npm ci           ← deterministic, production-only
+# ❌ COPY . .             ← copies node_modules, .git, secrets
+# ✅ Use .dockerignore     ← exclude node_modules, .env, .git
+# ❌ Running as root      ← security vulnerability
+# ✅ USER appuser          ← non-root user
+```
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+### .dockerignore
 
-**Slash command: `/tribunal-backend`** (or invoke directly for devops)
-**Active reviewers: `logic` · `security` · `dependency`**
+```
+node_modules
+.git
+.env
+.env.*
+*.md
+.github
+coverage
+dist
+```
 
-### ❌ Forbidden AI Tropes in DevOps
-1. **Hardcoded Secrets/Credentials** — never generate scripts or IaC configurations with embedded secrets. Always use secret managers (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) or CI/CD environment variables.
-2. **Missing State Management** — never generate Terraform code without defining a remote state backend.
-3. **Latest Tags in Containers** — never use `FROM image:latest` in Dockerfiles or Kubernetes manifests in production configurations; always pin specific tags or SHAs.
-4. **Permissive IAM Roles** — avoid wildcard `*` permissions in cloud IAM configurations; adhere to least privilege.
-5. **Ignoring Platform Cost** — avoid over-provisioning default resource requests/limits in Kubernetes without proper analysis.
+### Docker Compose
+
+```yaml
+# docker-compose.yml
+services:
+  app:
+    build:
+      context: .
+      target: runner
+    ports:
+      - "3000:3000"
+    environment:
+      - DATABASE_URL=postgres://postgres:postgres@db:5432/myapp
+      - REDIS_URL=redis://redis:6379
+    depends_on:
+      db:
+        condition: service_healthy
+      redis:
+        condition: service_started
+    restart: unless-stopped
+
+  db:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_DB: myapp
+      POSTGRES_USER: postgres
+      POSTGRES_PASSWORD: postgres
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  redis:
+    image: redis:7-alpine
+    volumes:
+      - redisdata:/data
+
+volumes:
+  pgdata:
+  redisdata:
+```
 
-### ✅ Pre-Flight Self-Audit
+---
 
-Review these questions before generating DevOps scripts or configurations:
-```text
-✅ Did I strictly avoid hardcoding any sensitive credentials or API keys?
-✅ Are all Docker or container image tags explicitly pinned?
-✅ Does the generated Infrastructure as Code (IaC) include appropriate networking defaults (private subnets, proper firewall rules)?
-✅ Are the Kubernetes manifests configured with resource limits and health probes?
-✅ Has logging and monitoring been wired up for the deployed components?
+## CI/CD with GitHub Actions
+
+### Standard Pipeline
+
+```yaml
+# .github/workflows/ci.yml
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true  # cancel stale runs on same PR
+
+jobs:
+  lint-and-test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: npm
+
+      - run: npm ci
+      - run: npm run lint
+      - run: npm run typecheck
+      - run: npm run test -- --coverage
+
+      - uses: actions/upload-artifact@v4
+        if: always()
+        with:
+          name: coverage
+          path: coverage/
+
+  build:
+    runs-on: ubuntu-latest
+    needs: lint-and-test
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: npm
+      - run: npm ci
+      - run: npm run build
+
+  deploy:
+    runs-on: ubuntu-latest
+    needs: build
+    if: github.ref == 'refs/heads/main'
+    environment: production
+    steps:
+      - uses: actions/checkout@v4
+
+      # Deploy to your platform (Vercel, Railway, Fly.io, etc.)
+      - run: npx vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }}
 ```
 
+### Security Scanning
+
+```yaml
+  security:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm audit --audit-level=high
+      - uses: github/codeql-action/analyze@v3
+        with:
+          languages: javascript-typescript
+```
 
 ---
 
-## 🤖 LLM-Specific Traps
-
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+## Deployment Strategies
 
-1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
-2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
-3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
-4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
+```
+Rolling Update (default):
+  Old ████████ → ██████░░ → ████░░░░ → ░░░░░░░░
+  New ░░░░░░░░ → ░░██████ → ░░░░████ → ████████
+  - Gradual replacement, zero downtime
+  - Rollback: redeploy previous version
+
+Blue/Green:
+  Blue  ████████ (live)     → ░░░░░░░░ (idle)
+  Green ░░░░░░░░ (staging)  → ████████ (live)
+  - Instant switch via load balancer
+  - Instant rollback (switch back)
+  - Requires 2x infrastructure
+
+Canary:
+  Stable ████████ (95%)  → ████████ (90%)  → ████████ (0%)
+  Canary ░░░░░░░░ (5%)   → ░░░░░░░░ (10%)  → ████████ (100%)
+  - Gradual traffic shift
+  - Monitor error rates/latency at each stage
+  - Rollback: stop canary traffic
+
+Feature Flags:
+  - Deploy code, control activation separately
+  - Risk-free deploys — flag is off by default
+  - A/B testing capability
+```
 
 ---
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
+## Secrets Management
+
+```yaml
+# ❌ NEVER:
+# - Hardcode secrets in code
+# - Commit .env files to git
+# - Use plain text in CI/CD configs
+# - Share secrets via Slack/email
+
+# ✅ ALWAYS:
+# GitHub Actions: Repository Secrets
+# - Settings → Secrets → Actions → New repository secret
+# - Reference: ${{ secrets.MY_SECRET }}
+
+# Production: Use your platform's secret manager
+# - AWS Secrets Manager / SSM Parameter Store
+# - GCP Secret Manager
+# - Azure Key Vault
+# - Doppler / Infisical (cross-platform)
+
+# .env management:
+# .env          → git-ignored, local development
+# .env.example  → committed, shows required keys (no values)
+```
 
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+---
 
-### ✅ Pre-Flight Self-Audit
+## Production Readiness Checklist
 
-Review these questions before confirming output:
 ```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
+Pre-Deploy:
+  □ All tests passing (unit, integration, E2E)
+  □ Security scan clean (npm audit, CodeQL)
+  □ Build succeeds in CI (not just locally)
+  □ Database migrations tested against production-size data
+  □ Environment variables verified in target environment
+  □ Rollback plan documented
+
+Monitoring:
+  □ Health check endpoint (/health)
+  □ Structured logging (JSON, not console.log)
+  □ Error tracking (Sentry, Datadog)
+  □ Uptime monitoring (external)
+  □ Alerting configured (PagerDuty, OpsGenie)
+
+Performance:
+  □ Response time P95 < 500ms
+  □ Error rate < 0.1%
+  □ Database connection pooling configured
+  □ CDN for static assets
+  □ Compression enabled (gzip/brotli)
+
+Security:
+  □ HTTPS only (HSTS enabled)
+  □ Rate limiting on all public endpoints
+  □ CORS configured (not wildcard *)
+  □ Security headers (helmet)
+  □ No secrets in code or logs
 ```
 
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.
+---