自动化开发的交互式流程蓝图An Interactive Blueprint for Agentic Development自動開発のインタラクティブなフローマップ

测试失败后怎么返修，评审通过后谁决定发布，线上故障又从哪里恢复？点击模块，可以查看执行步骤，并沿关联流程追踪这些分支。How does a failed test lead to repair, who decides to release after review, and where does recovery from a production incident begin? Open a module to inspect its steps and follow these branches across related flows.テスト失敗後はどう修復し、レビュー後のリリースは誰が決め、本番障害はどこから復旧するのでしょうか。モジュールを開くと、実行手順と関連フローの分岐をたどれます。

入口不同，交付链路共用Different entries, shared delivery異なる入口、共通のデリバリー経路

功能需求先明确范围和验收目标；用户报 Bug、巡检结果和线上故障进入任务确认、复现与去重。开发步骤由 GitLab Issue 中的 @Cursor 和 Webhook 衔接：理解需求，有歧义则询问，实施后自测，失败再返修。已有 MR 直接进入构建与测试，避免重复开发。Feature requests first establish scope and acceptance criteria. Bug reports, inspection findings and incidents go through confirmation, reproduction and deduplication. An @Cursor mention in a GitLab issue and a webhook connect the development steps: interpret the request, clarify ambiguity, implement, self-test and repair failures. Existing MRs enter build and test directly.機能要望では最初に範囲と受入条件を明確にします。不具合報告、点検結果、本番障害は、タスク確認・再現・重複排除へ進みます。GitLab Issueの@CursorとWebhookが開発手順をつなぎ、要件理解、曖昧な点の確認、実装、自己テスト、失敗時の修復を行います。既存MRは直接ビルドとテストへ進みます。

巡检与故障监控各有节奏。巡检定时运行核心业务并检查日志、资源和依赖；监控持续观察可达性、错误率与延迟。普通问题进入修复队列，影响线上则立即通知并补充调查简报。Inspection and incident monitoring run at different cadences. Scheduled inspections exercise core workflows and check logs, resources and dependencies. Monitoring continuously checks reachability, error rates and latency. Routine issues enter the repair queue; production impact prompts an immediate notification and an investigation briefing.点検と障害監視は異なる周期で動きます。点検は定期的に主要業務を実行し、ログ・リソース・依存関係を確認します。監視は到達性、エラー率、遅延を継続的に観測します。通常の問題は修復キューへ、本番影響があれば即時通知と調査報告へ進みます。

测试通过之后，还有发布判断Release decisions follow testingテストの先にあるリリース判断

CI 包含构建、单元／集成测试和测试环境中的用户流程验证。代码评审与 CI 必须对应同一个最新提交，并且没有阻塞问题。之后，风险分类器结合明确规则与 Agent 判断：低风险自动放行，高风险或无法确定时交给人审核。CI covers builds, unit and integration tests, and user workflows in a test environment. CI and code review must cover the same latest commit, with no blocking issues. A risk classifier then combines explicit rules with agent judgment: low-risk changes pass automatically; high or uncertain risk goes to human review.CIはビルド、単体・結合テスト、テスト環境でのユーザーフロー検証を含みます。CIとコードレビューは同じ最新コミットを対象とし、阻害事項がないことを確認します。その後、明示的ルールとAgentの判断でリスクを分類し、低リスクは自動承認、高リスクや判断困難な場合は人が確認します。

图中的几条边很重要：CI 或评审失败回到排查与返修；修复后重新跑 CI；反复失败、缺信息或缺权限时转人工。人工审核未批准则返修或停止，不能沿批准路径继续发布。Several edges carry the control logic: failed CI or review returns to investigation and repair; repairs rerun CI; repeated failures or missing information or access escalate to a person. A rejected human review leads to repair or a stop, not release.制御の要点は接続に現れます。CIやレビューの失敗は調査・修復へ戻り、修復後はCIを再実行します。失敗の反復や情報・権限の不足は人へ引き継ぎます。人が承認しなければ修復または停止とし、リリースへは進みません。

部署与恢复，都有明确出口Deployment and recovery have explicit exitsデプロイと復旧の出口を明確にする

部署前检查版本、配置依赖、迁移兼容与可恢复性，使用已测试产物和固定脚本，在同一环境中串行发布。部署后核对实际版本、连接和关键接口，再用测试账号验证核心流程、本次改动及业务结果。Pre-deployment checks cover versions, configuration dependencies, migration compatibility and recoverability. Tested artifacts and fixed scripts are deployed serially within an environment. After deployment, verify the running version, connections and key APIs, then use test accounts to validate core workflows, the change and business results.デプロイ前にバージョン、設定・依存関係、移行互換性、復旧可能性を確認します。テスト済み成果物と固定スクリプトを用い、同一環境には直列にリリースします。デプロイ後は稼働バージョン、接続、主要APIを確認し、テストアカウントで主要フロー、変更点、業務結果を検証します。

尚未部署时，失败意味着停止发布并通知；部署后的故障则暂停后续发布，评估安全恢复，按预授权方案回滚并复验。无法安全回滚或恢复失败时转人工，验收通过才记录版本与证据并通知完成。Before deployment, failure means stopping the release and notifying. After deployment, an incident pauses further releases, prompts a safe-recovery assessment, and follows a preauthorized rollback plan with rechecks. Unsafe rollback or failed recovery escalates to a person. Successful acceptance records the version and evidence before completion is announced.デプロイ前の失敗はリリース停止と通知を意味します。デプロイ後の障害では後続リリースを止め、安全な復旧を検討し、事前承認済み手順で戻して再検証します。安全に戻せない場合や復旧失敗時は人に引き継ぎます。受入確認を通過してから、バージョンと証跡を記録し完了を通知します。

让细节留在它所属的层级Keep detail at the right level詳細を適切な階層に置く

总图展示入口、判断与反馈；模块内部展示执行步骤；侧栏连接跨模块的上下游。读者可以深入局部，再回到全局。The overview shows entries, decisions and feedback. Modules reveal execution steps; the side panel links upstream and downstream flows. Readers can inspect a local process and return to the whole.全体図には入口、判断、フィードバックを示し、モジュール内には実行手順、サイドバーには上流・下流のつながりを示します。局所を詳しく見てから、全体に戻れます。

自动执行的边界必须先定好。图中“10 分钟未回复自动修复”的分支，需要明确从何时计时、哪些修复已获授权、失败后如何重试或回滚。这些约定尚待补齐；仅有等待超时，不能作为执行任意修复的授权。The limits of automatic action must be set first. The “repair automatically after 10 minutes without a reply” branch needs a defined timer start, a scope of authorized repairs, and retry or rollback rules. Those details remain to be specified; a timeout alone is not authorization for arbitrary repairs.自動実行の範囲は先に定める必要があります。「10分間返答がなければ自動修復」という分岐では、計時の開始点、承認済みの修復範囲、失敗時の再試行・ロールバック規則を決めなければなりません。これらはまだ未確定であり、時間切れだけで任意の修復が許可されるわけではありません。