Should you build your own Gumloop?

Build a closest honest personal substitute for Gumloop in an empty repository.
Use TypeScript, Node.js 22, PostgreSQL, Redis, BullMQ, and Docker Compose; do not offer alternative stacks.
The core loop is: build one AI-assisted workflow that connects user-approved files and APIs, execute it durably, expose retries and logs, and avoid claiming a general integration platform.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Implement a fixed trigger, transform, condition, and action workflow model rather than a general visual language.
Connect exactly two named services using documented APIs and encrypted credentials.
Store every run, step input hash, output summary, retry, and final status in PostgreSQL.
Make side effects idempotent and support retry from the failed step without repeating completed actions.
Add rate limits, backoff, dead-letter handling, manual replay, cancellation, and secret rotation.
Ship Docker Compose, health checks, sample workflows, tests, backups, and connector-limit documentation.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Do not claim to reproduce proprietary data, network liquidity, regulated access, or frontier infrastructure.
Deliberately leave out a broad connector marketplace.
Deliberately leave out unreviewed user code execution.
Deliberately leave out enterprise governance, guaranteed execution, and vendor-operated OAuth apps.
Finish by running the tests and listing the exact commands used.