Kartikm09/automation-reliability-console

# 自动化可靠性控制台 **一个多租户运营控制台，用于接收、标准化、监控和安全重放自动化执行。** [](https://github.com/Kartikm09/automation-reliability-console/actions/workflows/ci.yml) [](LICENSE) [](services/api) [](apps/web) ## 为什么开发此项目 本项目完全按照接收到的原样保留每个已签名的事件，然后应用 provider 适配器将其转换为标准的运行模型。持久化队列将接收与处理分离开来。PostgreSQL 状态机、RLS、私有 Storage、审计记录以及私有 Realtime 频道确保了操作员工作流的可控性。 ## 验证状态 专用的 Supabase 后端、七个 Edge Functions、私有 Storage、组织 Broadcast 频道、三个持久化队列以及加密的 Cron 触发 worker 均已部署并验证完毕。本地和托管数据库套件各自通过了 86 项 pgTAP 断言。[React 操作员控制台](https://automation-reliability-console.zw386.chatgpt.site) 已公开部署，其经过身份验证的桌面和移动端工作流在生产 URL 上测试通过。FastAPI 已在本地完成容器验证，因为在此环境中没有可用的经过身份验证的公共容器提供商。 ## 功能特性 | 领域 | 演示行为 | | --------------- | ----------------------------------------------------------------------- | | 租户安全 | PostgreSQL 强制实施的 owner、admin、operator 和 viewer 访问控制 | | 事件接入 | HMAC 签名、一次性凭证、重放窗口、请求限制 | | 标准化 | 自定义、类 n8n、类 Make 和类 Zapier 的合成适配器 | | 可靠性 | 幂等性、事件排序、重试、可见性超时、死信队列 | | 运营 | 运行时间线、事件、审批、重放谱系、审计证据 | | 数据处理 | 不可变的原始 payload、脱敏摘要、私有的已签名 artifacts | | 实时 UI | 私有组织 Broadcast 频道，配合权威的重新获取机制 | | 验证 | pgTAP、Deno、Pytest、Vitest、Playwright、密钥扫描、Docker 构建 | ## 产品导览  运行视图将供应商中立的状态、时间、步骤证据和重放控制整合在一起，且不会暴露不受限制的源 payloads。   ## 架构 ``` flowchart LR Provider[Automation provider] -->|HMAC webhook| Ingest[Supabase Edge Function] Ingest --> Raw[(Immutable raw event)] Ingest --> Queue[(PGMQ normalization queue)] Queue --> Worker[Idempotent queue consumer] Worker --> Adapter[Provider adapter] Adapter --> Canonical[(Runs, steps, incidents)] Canonical --> Broadcast[Private Realtime Broadcast] Broadcast --> Web[React operator console] Web -->|RLS-protected queries| Canonical Web --> Replay[Controlled replay request] Replay --> ReplayQueue[(PGMQ replay queue)] Api[FastAPI processing service] --> Adapter Api --> Canonical ``` Edge Functions 负责处理低延迟的平台边界和授权。FastAPI 负责处理可重用的繁重处理任务，并可在验证模式下独立运行。有关序列和状态机的详细信息，请参阅 [ARCHITECTURE.md](ARCHITECTURE.md)。 ## 演示工作流 1. 管理员创建自定义集成源。 2. 生成一次性 webhook 凭证，并仅以 SHA-256 哈希值的形式存储。 3. 已签名的事件被接收、保留并加入队列。 4. provider 适配器创建或更新标准运行和步骤时间线。 5. 失败的运行会创建一个 incident 和操作员通知。 6. 操作员确认 incident 并请求重放。 7. 管理员批准重放；worker 创建一个关联的合成运行。 8. 每个受保护的操作都会被追加到租户的审计历史中。 9. 另一个组织不会接收到任何数据行、已签名的 URL 或私有频道访问权限。 ## 仓库结构图 ``` apps/web/ React + TypeScript operator console services/api/ FastAPI normalization and processing service packages/contracts/ Shared browser-side validation contracts supabase/migrations/ Reproducible schema, RLS, queues, Cron, state machines supabase/functions/ Webhook, credentials, replay, approval, artifact functions supabase/tests/ pgTAP structure, RLS, and workflow tests tests/e2e/ Authenticated browser and tenant-isolation scenarios tests/fixtures/ Synthetic provider payloads docs/ Architecture, security, decisions, screenshots scripts/ Secret scan and environment-controlled demo setup ``` ## 快速开始 前置条件：Docker、Node.js 24、Python 3.11+、Deno 2 和 Supabase CLI 2。 ``` cp .env.example .env make setup make db-start make db-reset make dev ``` 容器化的前端运行在 `http://127.0.0.1:4173`，FastAPI 运行在 `http://127.0.0.1:8000`，本地 Supabase 运行在 `http://127.0.0.1:54321`。单独运行 `npm run dev` 会使用 Vite，地址为 `http://127.0.0.1:5173`。 演示密码永远不会被提交。请使用环境变量配置用户： ``` node scripts/setup-demo-users.mjs ``` ## 验证 ``` make lint make db-test make edge-test make api-test make web-test make build make docker-build ``` 测试计数和最新的确切命令请参阅 [TEST_REPORT.md](TEST_REPORT.md)。部署的实际情况，包括任何受外部阻断的组件，请参阅 [DEPLOYMENT_REPORT.md](DEPLOYMENT_REPORT.md)。 ## 安全模型 - 每个暴露的应用程序表都强制启用了 RLS。 - 授权辅助程序使用范围严格的 `SECURITY DEFINER` 函数和明确的 `search_path` 值。 - 包含凭证的集成表不能被浏览器角色读取；成员只能查询经过安全过滤的视图。 - 普通 web hook 事件不能由普通用户插入，也不能在接入后被修改。 - 审计和 incident-event 历史记录对普通用户是只读的（追加模式）。 - Artifact 路径有记录 backing，并且仅在租户授权后才进行签名。 - Service-role 凭证保留在服务器环境中，永远不会进入浏览器的构建包中。 在调整此项目之前，请阅读 [SECURITY.md](SECURITY.md) 和 [docs/security/threat-model.md](docs/security/threat-model.md)。 ## 展示的技能 Supabase Auth、PostgreSQL、RLS、pgTAP、私有 Storage、Edge Functions、Realtime Broadcast、PGMQ、pg_cron、React、严格的 TypeScript、TanStack Query、Zod、FastAPI、Pydantic、Pytest、Playwright、Docker、CI/CD、webhook 安全性、幂等性、状态机设计、可审计性以及运营 UX。 ## 招聘人员导览 从上面的架构图开始，检查 `supabase/tests/010_rls.test.sql` 中的 RLS 测试，遵循第二个迁移文件中的 `apply_canonical_event`，然后打开仪表盘、一个失败的运行、其对应的 incident 以及审计时间线。该导览大约需要十分钟，展示了系统边界、授权证明和操作员体验。 ## 客观的局限性 ## 项目作品集总结 设计并实现了一个多租户自动化运营控制台，采用了 React、FastAPI 和 Supabase。构建了签名 webhook 接入、不可变的原始事件存储、provider 标准化、持久化处理、incident 工作流、受控重放、私有 artifacts、RLS 隔离、Realtime 更新，以及全部使用合成数据的多层自动化测试。 ## 许可证 [Apache License 2.0](LICENSE)

标签：测试用例, 特征检测, 自动化攻击, 请求拦截, 逆向工具