{"id":"b6541f3c-7841-457d-b247-252bfaea4706","entityType":"agent","slug":"clawhub-fxbin-virtual-intelligent-dev-team","name":"Virtual Intelligent Dev Team","canonicalUrl":"https://www.xpersona.co/agent/clawhub-fxbin-virtual-intelligent-dev-team","canonicalPath":"/agent/clawhub-fxbin-virtual-intelligent-dev-team","generatedAt":"2026-10-10T14:42:35.972Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T12:15:51.819Z","emptyReason":null},"description":"Route complex software work with bounded, evidence-backed loops. Skill: Virtual Intelligent Dev Team Owner: fxbin Summary: Route complex software work with bounded, evidence-backed loops. Tags: latest:0.1.2 Version history: v0.1.2 | 2026-08-08T07:46:04.117Z | auto Version 0.1.2 of virtual-intelligent-dev-team - No functional or documentation changes detected; SKILL.md remains unchanged. - This release consolidates the current architecture and workflows without introducing new feat","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.4K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s177x7bk3bp1n32y264k0ewmhs8859wb:virtual-intelligent-dev-team","sourceUrl":"https://clawhub.ai/fxbin/virtual-intelligent-dev-team","homepage":"https://clawhub.ai/fxbin/skills/virtual-intelligent-dev-team","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/fxbin/virtual-intelligent-dev-team","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/fxbin/skills/virtual-intelligent-dev-team","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":63,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Route complex software work with bounded, evidence-backed loops. Skill: Virtual Intelligent Dev Team Owner: fxbin Summary: Route complex software work with boun"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T12:15:51.819Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T12:15:51.819Z","emptyReason":null},"stars":null,"forks":null,"downloads":1439,"packageName":null,"latestVersion":"0.1.2","tractionLabel":"1.4K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T12:15:51.818Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T12:15:51.819Z","lastCrawledAt":"2026-10-10T12:15:51.818Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T12:15:51.818Z","lastVerifiedAt":null,"highlights":[{"version":"0.1.2","createdAt":"2026-08-08T07:46:04.117Z","changelog":"Version 0.1.2 of virtual-intelligent-dev-team - No functional or documentation changes detected; SKILL.md remains unchanged. - This release consolidates the current architecture and workflows without introducing new features or fixes. - All existing routing, closure, and workflow mechanisms are preserved as previously documented.","fileCount":248,"zipByteSize":745866},{"version":"0.1.1","createdAt":"2026-08-08T07:24:41.951Z","changelog":"- Major documentation expansion: Added comprehensive references, assets, and templates for all workflow, governance, and delivery protocols. - Updated closure model: Clarified six closure layers, added delivery subgraph (Team Engine Lite), and refined stage council overlay structure. - Enhanced workflow detail: Expanded guidance on when and how to use each routing path, including stricter triggers for multi-expert and quick slice modes. - New \"worktree semantic review\" step: Adds confirmation logic for parallel-work and workspace isolation triggers. - Consistency updates throughout docs: Improved clarity on roles, routing, and governance boundaries. - GitHub Actions and metadata: Added .github workflows and explicit VERSION, LICENSE files for better project automation and compliance.","fileCount":248,"zipByteSize":745915},{"version":"0.1.0","createdAt":"2026-07-01T07:24:28.663Z","changelog":"virtual-intelligent-dev-team 0.1.0 - Initial release of a bounded work-loop router for complex software tasks. - Introduces semantic routing to the smallest defensible workflow with one lead specialist from a set of 8. - Supports layered closure processes (planning, routing, delivery, iteration, release, drills, team engine lite, and optional stage council). - Attaches copilots and governance agents only when they provide delivery value. - Handles multi-domain, fuzzy, or cross-specialty requests with confirmation for intent and verifiable workflow closure. - Emphasizes evidence-based completion and durable workflow state for resumability.","fileCount":44,"zipByteSize":103246}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s177x7bk3bp1n32y264k0ewmhs8859wb:virtual-intelligent-dev-team","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T14:42:35.966Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-fxbin-virtual-intelligent-dev-team/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T12:15:51.819Z","emptyReason":null},"readme":"Skill: Virtual Intelligent Dev Team\n\nOwner: fxbin\n\nSummary: Route complex software work with bounded, evidence-backed loops.\n\nTags: latest:0.1.2\n\nVersion history:\n\nv0.1.2 | 2026-08-08T07:46:04.117Z | auto\n\nVersion 0.1.2 of virtual-intelligent-dev-team\n\n- No functional or documentation changes detected; SKILL.md remains unchanged.\n- This release consolidates the current architecture and workflows without introducing new features or fixes.\n- All existing routing, closure, and workflow mechanisms are preserved as previously documented.\n\nv0.1.1 | 2026-08-08T07:24:41.951Z | auto\n\n- Major documentation expansion: Added comprehensive references, assets, and templates for all workflow, governance, and delivery protocols.\n- Updated closure model: Clarified six closure layers, added delivery subgraph (Team Engine Lite), and refined stage council overlay structure.\n- Enhanced workflow detail: Expanded guidance on when and how to use each routing path, including stricter triggers for multi-expert and quick slice modes.\n- New \"worktree semantic review\" step: Adds confirmation logic for parallel-work and workspace isolation triggers.\n- Consistency updates throughout docs: Improved clarity on roles, routing, and governance boundaries.\n- GitHub Actions and metadata: Added .github workflows and explicit VERSION, LICENSE files for better project automation and compliance.\n\nv0.1.0 | 2026-07-01T07:24:28.663Z | auto\n\nvirtual-intelligent-dev-team 0.1.0\n\n- Initial release of a bounded work-loop router for complex software tasks.\n- Introduces semantic routing to the smallest defensible workflow with one lead specialist from a set of 8.\n- Supports layered closure processes (planning, routing, delivery, iteration, release, drills, team engine lite, and optional stage council).\n- Attaches copilots and governance agents only when they provide delivery value.\n- Handles multi-domain, fuzzy, or cross-specialty requests with confirmation for intent and verifiable workflow closure.\n- Emphasizes evidence-based completion and durable workflow state for resumability.\n\nArchive index:\n\nArchive v0.1.2: 248 files, 745866 bytes\n\nFiles: .github (0b), .github/workflows (0b), .github/workflows/pages.yml (775b), agents (0b), agents/openai.yaml (1575b), assets (0b), assets/auto-run-plan-template.json (1210b), assets/beta-cohort-matrix-template.md (1184b), assets/beta-cohort-plan-template.json (2530b), assets/beta-feedback-ledger-template.md (791b), assets/beta-program-overview-template.md (828b), assets/beta-ramp-plan-template.json (1813b), assets/beta-round-report-template.json (690b), assets/beta-simulation-config-template.json (1394b), assets/completion-evidence-template.json (986b), assets/contract-spec-template.json (1443b), assets/debt-ledger-template.json (704b), assets/delivery-cycle-report-template.json (832b), assets/delivery-status-template.yaml (391b), assets/distilled-patterns-template.md (267b), assets/end-to-end-example.md (19572b), assets/external-agent-backend-plan-template.json (1650b), assets/iteration-ledger-template.md (358b), assets/iteration-plan-template.json (1468b), assets/micro-practice-ledger-template.json (287b), assets/post-release-feedback-ledger-template.md (537b), assets/post-release-rollout-summary-template.md (693b), assets/post-release-signal-report-template.json (1494b), assets/post-release-triage-summary-template.md (405b), assets/pre-development-phase-template.md (210b), assets/pre-development-progress-master-template.md (514b), assets/pre-development-project-overview-template.md (592b), assets/pre-development-task-breakdown-template.md (799b), assets/product-contract-questions-template.md (286b), assets/product-delivery-brief-template.md (656b), assets/project-context-template.md (706b), assets/quick-slice-brief-template.md (523b), assets/round-memory-template.md (220b), assets/round-reflection-template.md (339b), assets/sample-delivery-cycle-report.json (4863b), assets/self-feedback-template.md (208b), assets/simulated-user-profile-template.json (654b), assets/stage-council-plan-template.json (1039b), assets/team-work-order-template.json (1612b), assets/technical-governance-change-plan-template.md (343b), assets/technical-governance-release-checklist-template.md (460b), docs (0b), docs/agents.html (11894b), docs/architecture.html (13230b), docs/assets (0b), docs/assets/site.css (22223b), docs/assets/site.js (2086b), docs/design-philosophy.md (6296b), docs/engineering.html (13029b), docs/index.html (15652b), docs/matrix.html (10406b), docs/README.md (3485b), docs/release-notes.md (14052b), docs/usage-guide.md (7193b), evals (0b), evals/eval-meta.json (1360b), evals/evals.json (136603b), evals/stress-scenarios (0b), evals/stress-scenarios/baseline-deleted.json (995b), evals/stress-scenarios/drill-multi-session-lifecycle.json (1305b), evals/stress-scenarios/drill-soft-orchestration-degradation.json (1254b), evals/stress-scenarios/frontend-backend-contract-mismatch.json (1410b), evals/stress-scenarios/json-corrupt.json (981b), evals/stress-scenarios/lead-skips-verifier.json (1062b), evals/stress-scenarios/resume-plan-drift.json (1262b), evals/stress-scenarios/routing-circuit-breaker-escalation.json (1360b), evals/stress-scenarios/routing-soft-fallback-downgrade.json (1126b), evals/stress-scenarios/routing-tier-selection-boundary.json (1252b), evals/stress-scenarios/verifier-always-pass.json (1071b), evals/stress-scenarios/worker-self-pass.json (1065b), LICENSE (1062b), README.md (22327b), references (0b), references/agent-catalog.md (13013b), references/anti-entropy-governance.md (4185b)\n\nFile v0.1.2:SKILL.md\n\n---\nname: virtual-intelligent-dev-team\narchetype: router\ndescription: Bounded work-loop router for complex software tasks. Routes to the smallest defensible workflow with one semantic lead from 8 specialists (Java Virtuoso, Sentinel Architect, Technical Trinity, Code Audit Council, Git Workflow Guardian, World-Class Product Architect, Data Pipeline Guardian, API Contract Sentinel), attaches copilots only when useful, asks intent-confirmation for fuzzy ideas, and closes with verifiable evidence.\n---\n\n# Virtual Intelligent Dev Team\n\nRoute complex software work into the smallest defensible delivery workflow, keep one semantic lead, and close the task with verifiable evidence and a resume anchor.\n\n## Positioning\n\nThis skill is a bounded work-loop router for complex tasks. Routing is one of its closures; the full set is six closure layers, one delivery subgraph, and one optional stage-council overlay:\n\n1. `Planning closure`\n - Large rewrites, migrations, and project-wide transformations get a lightweight analysis / plan / progress pack before implementation.\n2. `Routing closure`\n - Work is routed across lead, assistant, governance, and process tracks based on task shape, risk, stack, and workflow signals.\n3. `Delivery closure`\n - Narrow feature and bug-fix slices use a quick slice brief, durable project context, delivery status, targeted verification, and self-review.\n4. `Iteration closure`\n - Optimization loops preserve baseline, round memory, self-feedback, `keep / retry / rollback / stop`, `pivot`, and `resume`.\n5. `Release closure`\n - Release readiness uses a formal `ship` / `hold` gate and bootstraps the next remediation loop when needed.\n6. `Drill closure`\n - Offline drills verify rollback, resume, and release-gate bootstrap paths.\nDelivery subgraph:\n\n- `Team Engine Lite`（Delivery closure 内子图，非独立层）\n - Code-facing delivery uses Worker / Verifier separation, max-cycle retry, remediation patch, controlled real subagent runtime eligibility, external-agent soft orchestration fallback, and a DeliveryCycleReport before Lead acceptance.\n - Verifier 独立性由\"禁止上游预判下游\"硬约束(P0-3)保证,而非独立成层。详见 `references/team-engine-lite-protocol.md` 和 `references/verifier-extraction-guide.md`。\nOptional overlay:\n\n- `Stage council overlay`\n - Product discovery and prototype design can expand into phase-level councils under `World-Class Product Architect` without replacing the top-level lead, workflow bundle, or Team Engine Lite verification.\n\nRuntime rule:\n\n- When routing alone is not enough, return the smallest matching workflow bundle and resume anchor instead of inventing a new ceremony.\n\n## Routing goal\n\nRoute complex software requests into the smallest defensible workflow bundle, keep one semantic lead, and attach only assistants, governance, and artifacts that materially improve delivery fidelity.\n\n## Trigger cues\n\n- multi-domain software delivery\n- fuzzy ideas where product opportunity, prototype exploration, technical feasibility, architecture risk, or delivery planning could all be plausible\n- quick implementation or bug-fix slice\n- rewrite / migration / plan-before-coding\n- repeated optimization or retry loops\n- staged beta validation or rollout risk control\n- release readiness / ship-hold decisions\n- git workflow, rollback, or governance-sensitive delivery\n- repository AI onboarding, `AGENTS.md`, or project-local `.agents/skills/` context capture\n\n## When to use\n\nUse this skill when:\n\n- The user does not know which研发 / 产品 / 技术治理 specialist should own the task.\n- The task spans two or more domains such as code, architecture, product definition, frontend UX, security, audit, release, or Git workflow.\n- The user asks for a small implementation or bug-fix slice that needs quick context, acceptance criteria, and verification.\n- The user asks for a large rewrite, migration, overhaul, project-wide refactor, or explicitly wants planning before coding.\n- The user needs a cross-domain delivery decision such as audit plus implementation, product scope plus API contract, risky refactor plus staged governance, or release guardrails.\n- The task needs structured coordination, governance, or workflow guardrails.\n\nUse bounded iteration only when the request benefits from it:\n\n- explicit optimization loops\n- benchmark or regression comparison\n- repeated retries with evidence required\n- candidate comparison before committing to a direction\n\nUse pre-development planning only when the request benefits from it:\n\n- rewrite or migrate a whole project or major subsystem\n- architecture overhaul before implementation\n- project-wide refactor with dependency-aware phase planning\n- \"plan first, code later\" requests that need durable progress tracking\n\nIf the task is simple and clearly single-domain, keep routing lightweight.\n\n## Quick examples\n\n| User request | Route shape | Why |\n|-------------|-------------|-----|\n| \"前端性能慢，怎么优化？\" | Direct Answer | Single-domain, well-scoped question |\n| \"微服务架构拆分规划\" | Multi-Expert | Spans architecture, product, and delivery |\n| \"设计一个用户认证系统\" | Full Workflow | Requires product spec + API contract + implementation |\n| \"这个 PR 有安全问题吗？\" | Expert Routing | Clear specialist domain (security audit) |\n| \"帮我重构这段 Python 代码\" | Quick Slice | Code-editing refactor needs delivery evidence |\n| \"发布这个版本到生产环境\" | Full Workflow | Needs release gate + ship/hold decision |\n| \"设计 Kafka 实时数据管道\" | Expert Routing | Clear domain: Data Pipeline Guardian |\n| \"API 版本兼容性怎么保证\" | Expert Routing | Clear domain: API Contract Sentinel |\n\n## Key terms\n\n- **Workflow bundle** - Parameterized pipeline for a closure type (delivery/governance/lifecycle)\n- **Quick slice** - Narrow, time-boxed implementation with minimal ceremony\n- **Baseline** - Snapshot of current state before changes, for comparison and rollback\n- **Round memory** - Accumulated context across iteration rounds\n- **Self-feedback** - LLM evaluates its own output against acceptance criteria\n- **Pivot** - Change direction based on new evidence or failed validation\n- **Resume anchor** - File path where workflow state is preserved for interruption recovery\n- **Project context** - Durable project rules, commands, architecture constraints, forbidden changes, and verification defaults shared across slices\n\n## Workflow\n\n1. Identify task type, risk level, language stack, and Git/process needs.\n2. Choose the smallest output mode with [references/mode-selection-protocol.md](references/mode-selection-protocol.md): Direct Answer, Multi-Expert Execution, Expert Routing, or Full Workflow.\n3. Keep Direct Answer advice-only. If the user asks for code edits, refactors, bug fixes, verification, commits, release readiness, or repeated iteration, route to the smallest delivery bundle instead. Use Multi-Expert Execution only when multiple specialist perspectives materially change the result; spawn real experts only when runtime evidence exists, otherwise label the result as soft expert orchestration.\n4. If the request is a narrow implementation or bug fix, use quick slice delivery instead of a full product or planning workflow.\n5. Choose one lead agent.\n6. Add one or two assistant agents only when they add clear value.\n7. Enable governance or process guardrails only when needed.\n8. Use a compact handoff when lead and assistants need structured coordination.\n9. If the request is primarily about building AI-readable project context, route execution to `skill-forge` and its project knowledge capture protocol after the software-risk lanes are identified.\n10. If the request is a fuzzy idea or low-information route-changing ask, ask one intent-confirmation question before treating the provisional route as final.\n10.5. Worktree semantic review: `needs_worktree` from the router is a keyword-based first pass, not a final verdict. When it is true, confirm the task genuinely involves parallel work or workspace isolation; if it was a false trigger (e.g. the user mentioned \"two\" in passing but the work is a single coherent task), downgrade and do not force a worktree. When it is false but the task clearly needs parallel isolation (multiple independent changes that must not interfere), suggest a worktree to the user and explain the benefit. Record the review outcome as a route-changing assumption.\n11. Apply execution-quality guardrails: surface route-changing assumptions, keep the smallest defensible bundle, limit scope surgically, and define verifiable closure.\n12. For broad, repeated-failure, release, beta, multi-agent, or drift-prone work, apply goal framing: success evidence, stop condition, and non-goals must be explicit before implementation.\n13. For code-facing routes, apply the Harness constraint gate before implementation: create or refresh `.vidt/harness/engineering-constraints.md`.\n14. For changes that add or retire guards, fallbacks, adapters, duplicate owners, compatibility paths, schema, persistence, or source-of-truth behavior, apply anti-entropy governance before choosing delete, compat, or confirmation paths.\n15. For code-facing, release-facing, Git-facing, or remediation routes, apply Team Engine Lite: Worker can produce, Verifier can return pass/fail/hold/spec_violation, and Lead can accept only after a DeliveryCycleReport.\n16. If the user explicitly asks for multi-agent / subagent / parallel agent execution, or `/auto` reaches an eligible workflow, build a controlled real subagent runtime plan with three tiers: `real_subagent_runtime` (host exposes spawn / wait / merge), `single_backend_multi_session` (host exposes create_session / kill_session / restart_session; session is the circuit-breaker unit), or `soft_orchestration_only` (no isolation; `known-shortcut:` ceiling). The host downgrades to the highest tier it can actually enforce; never upgrade beyond proven capability.\n17. If external Agent backends are available but real subagent runtime is not proven, check whether the host supports `single_backend_multi_session` (session-level circuit breaking) before falling back to `soft_orchestration_only`. `soft_orchestration_only` is the last resort with a `known-shortcut:` ceiling (no session kill / restart / context isolation).\n18. **Real Subagent Execution Guide**: When spawning Worker/Verifier/Explorer agents, use actual Agent tool invocations with independent prompts and contexts. See [references/subagent-exec-guide.md](references/subagent-exec-guide.md) for complete execution templates including Worker-Verifier cycles, parallel implementation, and Explorer-Worker patterns.\n19. If the user asks for optimization, repeated improvement, benchmark comparison, or another round, enter bounded iteration instead of open-ended self-looping.\n20. If the user asks whether the current version can ship, submit, or pass formal acceptance, run the release gate instead of answering from a benchmark summary alone.\n21. If product discovery, product strategy, PRD, user research, competitor analysis, metrics, roadmap, prototype design, high-fidelity UI, design systems, or explicit expert-team phrasing would make a single product generalist too broad, apply the stage council protocol under `product-spec-deliver`.\n22. Before any completion, readiness, commit, merge, release, or handoff claim, preserve fresh evidence slots: action, result, covered scope, uncovered scope, residual risk, and confidence grade.\n23. Produce one unified response instead of disconnected role fragments.\n\n## Output template\n\n**For Direct Answer Mode (Default):**\n- Technical Analysis\n- Solution (with code/config examples)\n- Implementation Steps\n- Expected Results\n\n**For Multi-Expert Execution Mode:**\n- Expert Team Roster (2-4 experts)\n- Individual Expert Analyses (actual execution outputs only when real runtime exists; otherwise clearly labeled expert-lens analysis)\n- Synthesized Solution (integrated from all perspectives)\n- Implementation Steps (unified path)\n\n**For Expert Routing Mode:**\n- Expert Selection (one line: who and why)\n- Expert's Technical Analysis\n- Solution\n- Implementation Steps\n\n**For Full Workflow Mode:**\n- `Selected route`\n - lead, assistants, workflow bundle, and why this route won\n- `Fallback`\n - clarification path or downgraded route when confidence or evidence is weak\n- `Next step`\n - smallest executable action, required artifact, and resume anchor\n\n## Runtime references\n\nRead indexes first; do not flatten the whole skill into this file. Authoritative entry points:\n\n- [references/playbook-index.md](references/playbook-index.md) — playbooks, protocols, and core reference index\n- [references/tooling-command-index.md](references/tooling-command-index.md) — scripts, commands, and asset entrypoints\n- [references/agent-catalog.md](references/agent-catalog.md) — 8 lead specialists and their constraints\n- Maintainer-facing docs: [README.md](README.md) and [docs/README.md](docs/README.md)\n\n## Governance & Observability (v5.0+)\n\nThe skill exposes a governance layer alongside the routing layer:\n\n- **Decision log**: every route decision appends one JSON line to\n `.vidt/metrics/decision-log.jsonl`. Schema: `references/decision-log.schema.json`.\n- **Agent manifest**: each lead agent in `references/agent-catalog.md` and\n `references/routing-rules.json` declares `Constraints` (hard\n guardrails the LLM must enforce) and `Evidence Requirements` (what the\n agent must produce before claiming done/ready/ship).\n- **Health check**: `scripts/check_harness_health.py` validates Agent\n Identity, Agent Manifest, Routing Rules, Workflow Bundles, Decision Log\n readability, and Language Profiles presence.\n- **Dashboard**: `scripts/inspect_decision_log.py` summarizes the decision\n log as JSON / Markdown / self-contained HTML.\n- **Telemetry**: `scripts/emit_telemetry.py` writes per-layer execution\n traces with intent drift probe to `.vidt/metrics/telemetry.jsonl`\n (contract: [references/observability-protocol.md](references/observability-protocol.md)).\n- **Layer health**: `scripts/inspect_decision_log.py --health-report`\n emits per-layer SLO status, failure counts, and breaker state from\n telemetry + circuit breaker state files.\n- **Stress scenarios**: `scripts/run_stress_scenarios.py` runs 12\n failure scenarios — 7 multi-role failure scenarios (contract mismatch /\n worker self-pass / lead skips verifier / verifier always-pass / baseline\n deleted / json corrupt / resume plan drift) plus 5 v6.0.1 routing/drill\n scenarios (tier selection boundary / soft fallback downgrade / circuit\n breaker escalation / multi-session lifecycle / soft-orchestration\n degradation), each with ONE runnable check. Output carries `trace_summary`\n (machine-validated: real file paths + caller list, non-empty or scenario\n fails), `fix_scope` (`root-cause` / `symptom`), and `scenario_outcome`\n (`all_scenarios_passed` / `semantic_warning` / `semantic_error`); `symptom`\n triggers benchmark warn, not fail. Status enum: `passed` / `failed` /\n `correctly_not_caught` (see §Release Notes v6.0.1 for migration). Passing\n gate: 12 scenarios executed, `trace_summary` all non-empty, `fix_scope`\n root-cause ratio >= 80%. Field-name consistency enforced by\n `quick_validate.py` (_STRESS_REQUIRED_TOP_FIELDS / _STRESS_VALID_METHODS).\n\nTypical invocations (health snapshot, decision-log summary, markdown/HTML report) live in [references/tooling-command-index.md](references/tooling-command-index.md) §一; stress scenarios in §九.\n\n## Language Profile Loading (v5.0+)\n\nLanguage support is split into three orthogonal layers:\n\n1. **Routing** — `references/routing-rules.json` → language_profiles\n decides which lead agent handles the request (13 profiles: python / go\n / nodejs / rust / java / kotlin / swift / cpp / csharp / php / ruby /\n elixir / scala).\n2. **Context** — `references/language-profiles.yaml` → profiles.\n injects the matched agent's working memory with ecosystem defaults,\n idiomatic conventions, and canonical verification commands.\n3. **Constraints** — `language-profiles.yaml → profiles..harness_constraints`\n feeds language-specific guardrails that the LLM must enforce, layered\n on top of the matched agent's `agent_rules[*].constraints`.\n\nWhen a request matches a language keyword in `routing-rules.json`:\n\n1. Route the task to the profile's `lead_agent`.\n2. Load the matching entry from `language-profiles.yaml`; the YAML\n covers all 13 routed language profiles.\n3. Inject into the agent's context: ecosystem, conventions, verification\n commands, and `harness_constraints`.\n\nIf a new language is added to `routing-rules.json`, add the matching YAML\nprofile in the same pass so the LLM gets structured ecosystem defaults,\nverification commands, and harness constraints. Run\n`python scripts/check_language_profiles.py --pretty` to validate the two\nfiles stay in sync.\n\n**Java is an exception**: routing still prefers `Java Virtuoso`, and the\nJava entry in `language-profiles.yaml` injects baseline toolchain info\n(Gradle / Maven, Spring Boot 3.x, JVM 21+) that complements — but does\nnot replace — Java Virtuoso's depth.\n\n## Built-in checks\n\nUse deterministic routing inspection when needed:\n\n```bash\npython scripts/route_request.py --text \"\" --config references/routing-rules.json\n```\n\nRun semantic regression after changing routing, guardrails, examples, or this skill:\n\n```bash\npython scripts/validate_virtual_team.py --pretty\n```\n\n## Runtime Routing\n\nRuntime routing rules (primary routes, stage council overlays, score model, thresholds, and fallback rules) and workflow bundle definitions (12 bundles with use-when / sequence / resume anchor / confidence levels) live in dedicated reference files:\n\n- [references/runtime-routing-rules.md](references/runtime-routing-rules.md) — Primary Routes, Stage Council Overlays, Routing Score Model, Thresholds, Fallback Rules\n- [references/workflow-bundles.md](references/workflow-bundles.md) — 12 workflow bundle definitions and Bundle Confidence Levels (each bundle has a stable `bundle_id` anchor for external reference; pseudo-bundles like `decline-and-reroute` are documented separately)\n\n## Release Notes\n\n完整版本历史、字段迁移指南和 Memory Keeper 计划见 [docs/release-notes.md](docs/release-notes.md)。\n\n### v6.0.19 (2026-07-26)\n\n- 路由生成 worktree 与迭代命令时直接复用已经解析的主仓 `state-root`，避免再次通过 shell 猜测路径。\n\n### v6.0.18 (2026-07-26)\n\n- 将 decision log 和 durable iteration state 统一写入主仓 state-root，修复 linked worktree、含空格路径和持久状态分裂。\n- worktree 路由新增显式否定与纯规划抑制；change-localization 排除产品定位和只读审计。\n- validator/test fixture 改用自动清理的系统临时目录，避免 `.tmp-validation` 泄漏污染仓库门禁。\n\n### v6.0.17 (2026-07-25)\n\n收窄 worktree 关键词初筛表（移除高频误触发的泛词，保留语义明确的并行隔离信号），\n补负向 eval 锁定项目管理语境不应触发 worktree。v6.0.11–v6.0.16 依次引入了定位与\n迭代约束强化、改动点定位与目标项目知识库协议、worktree 状态目录归属、`.vidt/`\n状态目录收拢、worktree 两层判断、eval 断言与激活条件修复。详见 docs/release-notes.md。\n\n### v6.0.10 (2026-07-23)\n\nPages artifact action 升级到 v4，并删除 custom Actions 静态部署链不使用的\n`.nojekyll`；发布门禁与回归覆盖改为校验真实 artifact 边界。\n\nFile v0.1.2:docs/README.md\n\n# Virtual Intelligent Dev Team Docs\n\n`docs/` 同时承担公开站点和维护者文档，但两者职责不同：\n\n- 五个 HTML 页面面向浏览者，构成 GitHub Pages 静态站。\n- Markdown 文档面向使用者与维护者，解释操作方式、设计理念和版本变化。\n- 运行时规则仍以 `../SKILL.md` 和 `../references/` 为真源。\n\n## 公开站点\n\n| 页面 | 主要内容 |\n| --- | --- |\n| [index.html](index.html) | 定位、核心闭环、最短上手路径 |\n| [architecture.html](architecture.html) | 六层 Closure、Team Engine Lite、runtime 与 12 个 Workflow Bundles |\n| [engineering.html](engineering.html) | Harness、标准交接对象、反熵治理与完成证据 |\n| [agents.html](agents.html) | 8 个专家角色、路由边界与两个 Stage Council |\n| [matrix.html](matrix.html) | 14 维能力对比、适用边界与取舍 |\n\n所有页面共享：\n\n- `assets/site.css`：视觉 tokens、布局、组件、响应式与可访问性样式\n- `assets/site.js`：移动端导航、复制按钮和轻量页面状态\n\n站点不使用构建工具、CDN、远程字体或前端框架。`deck.html` 及其专用资源已经退役；演示内容已归并进五个正式页面，不保留兼容入口。\n\n## GitHub Pages 部署\n\n本 skill 会通过仓库级发布 workflow 以 subtree 形式发布到独立仓库\n`fxbin/virtual-intelligent-dev-team`。subtree 发布后，\n`.github/workflows/pages.yml` 位于目标仓库根目录，并把 `./docs` 上传为 Pages artifact。\n该流程不执行 Jekyll 构建，因此不需要 `.nojekyll`。\n\n预期公开地址：\n\n- \n\n注意：GitHub 的 `blob/.../docs/index.html` 页面只显示 HTML 源码，不会渲染站点；必须访问 Pages 地址。第一次启用时，目标仓库的 **Settings → Pages → Source** 需要允许 **GitHub Actions**。workflow 成功运行前，不应宣称线上站点已部署。\n\n## 本地预览\n\n从独立 skill 仓库根目录运行：\n\n```bash\npython -m http.server 8000\n```\n\n访问 。\n\n从 `skill-hub` 仓库根目录运行同一命令时，访问：\n\n\n\n不要直接用 `file://` 作为最终验收方式；本地 HTTP 能更接近 Pages 的路径与资源加载行为。\n\n## 推荐阅读顺序\n\n第一次使用：\n\n1. [../README.md](../README.md)\n2. [usage-guide.md](usage-guide.md)\n3. [index.html](index.html)\n\n理解设计与维护：\n\n1. [design-philosophy.md](design-philosophy.md)\n2. [architecture.html](architecture.html)\n3. [engineering.html](engineering.html)\n4. [../SKILL.md](../SKILL.md)\n\n版本变化：\n\n- [release-notes.md](release-notes.md)\n\n## 文档更新规则\n\n- 行为、路由或协议变化先改真源，再同步公开 HTML 和回归覆盖。\n- 五个页面的公共视觉或交互只在 `assets/site.css` / `assets/site.js` 修改。\n- 删除或重命名公开页面时，同步发布脚本、站内导航、README 与测试。\n- 不把 `SKILL.md` 扩写成手册；详细解释留在 `references/` 或 `docs/`。\n- 每次修改本 skill 都必须更新 `VERSION` 并通过 `quick_validate`。\n\n## 运行时真源\n\n- `../SKILL.md`\n- `../references/playbook-index.md`\n- `../references/agent-catalog.md`\n- `../references/workflow-bundles.md`\n- `../references/team-engine-lite-protocol.md`\n- `../references/*.schema.json`\n\n公开站点负责解释和导航，不替代上述运行时契约。\n\nFile v0.1.2:README.md\n\n# Virtual Intelligent Dev Team\n\n[![Version](https://img.shields.io/badge/version-v6.0.19-8b5cf6?style=flat-square)](./VERSION)\n[![License](https://img.shields.io/badge/license-MIT-10b981?style=flat-square)](./LICENSE)\n[![Status](https://img.shields.io/badge/status-production--ready-f59e0b?style=flat-square)]()\n[![Archetype](https://img.shields.io/badge/archetype-router-06b6d4?style=flat-square)](./SKILL.md)\n[![Agents](https://img.shields.io/badge/specialist_agents-8-3b82f6?style=flat-square)](./references/agent-catalog.md)\n[![Closures](https://img.shields.io/badge/closure_layers-6-a78bfa?style=flat-square)](https://fxbin.github.io/virtual-intelligent-dev-team/architecture.html)\n[![Languages](https://img.shields.io/badge/language_profiles-13-10b981?style=flat-square)](./references/language-profiles.yaml)\n[![Python](https://img.shields.io/badge/python-3.8+-3776ab?style=flat-square&logo=python&logoColor=white)]()\n\n> **面向复杂软件工作的闭环协调层**：用六层闭环承接专家路由 · 计划 · 执行 · 迭代 · Beta · Release · Feedback，并在 Delivery closure 内嵌 Team Engine Lite 对抗式验收，以工程约束门禁 · 反熵治理 · 自优化循环保障交付质量。\n> 适合接手\"单个专家已经不够、单轮回答也不够\"的复杂软件任务。\n\n---\n\n## 在线站点\n\n> 文档站使用纯静态 HTML/CSS/JS，可由独立仓库的 GitHub Actions 直接部署到 GitHub Pages。\n\n| 入口 | 说明 | 链接 |\n| --- | --- | --- |\n| 落地页 | 项目总览：定位 / 痛点 / 六层闭环 / Team Engine Lite / 8 Agent / Quick Start | [fxbin.github.io/virtual-intelligent-dev-team](https://fxbin.github.io/virtual-intelligent-dev-team) |\n| 闭环架构 | 六层 Closure、Delivery 子图与 Stage Council overlay | [Architecture](https://fxbin.github.io/virtual-intelligent-dev-team/architecture.html) |\n| 工程化四支柱 | Harness 门禁 · Team Engine Lite · 反熵治理 · 自优化循环 | [Engineering](https://fxbin.github.io/virtual-intelligent-dev-team/engineering.html) |\n| 8 Agent 角色图谱 | 8 个专家的职责、领域与证据要求 | [Agents](https://fxbin.github.io/virtual-intelligent-dev-team/agents.html) |\n| 能力矩阵对比 | 14 个维度对比本项目与普通多专家提示词 | [Matrix](https://fxbin.github.io/virtual-intelligent-dev-team/matrix.html) |\n\n> 独立仓库本地预览：运行 `python -m http.server 8000` 后访问 `http://localhost:8000/docs/`。在 `skill-hub` 根目录启动时，访问 `/virtual-intelligent-dev-team/docs/`。\n\n---\n\n## 项目定位\n\n`virtual-intelligent-dev-team` 是一个面向复杂软件工作的智能协作项目。\n\n它不只是\"专家角色路由器\"，而是把研发、产品、分轮内测、技术治理、发布门禁、显式 `/auto` 自动运行，以及状态驱动恢复，收拢成一个可持续迭代的闭环工作流。\n\n一句话说：\n\n它适合接手\"单个专家已经不够、单轮回答也不够\"的复杂软件任务。\n\n---\n\n## 🚀 5 分钟快速上手\n\n### 0. 运行维护脚本前安装依赖\n\n直接调用 skill 不需要额外安装；如果要运行路由、schema、遥测或回归脚本，先执行：\n\n```bash\npython -m pip install -r requirements.txt\n```\n\n`requirements.txt` 统一声明 `jsonschema` 与 `PyYAML`，避免不同维护环境依赖隐式存在。\n\n### 1. 最简单的使用场景（小切片交付）\n\n```bash\n# 场景：实现一个小功能或修复一个 bug\n/virtual-intelligent-dev-team 实现用户登录功能的邮箱验证\n```\n\n**会发生什么：**\n- 自动路由到 `Technical Trinity`（通用后端工程专家）\n- 生成 Quick Slice Brief（包含目标、范围、验收条件）\n- 实现代码并保留 delivery status 和完成证据\n- 给出下一步建议（测试、提交、发布门禁等）\n\n### 2. 模糊想法确认（意图确认）\n\n```bash\n# 场景：有一个想法，不确定该从产品、原型、技术还是架构入手\n/virtual-intelligent-dev-team 我想做一个用户画像功能\n```\n\n**会发生什么：**\n- 先给出 5 个确认方向选项：\n - `product-opportunity`：产品机会验证\n - `prototype-exploration`：原型探索\n - `technical-feasibility`：技术可行性评估\n - `architecture-risk`：架构风险分析\n - `delivery-plan`：交付拆解\n- 用户选择后，路由到对应的 Lead Agent 或 Workflow Bundle\n\n### 3. 大重构规划（开发前规划）\n\n```bash\n# 场景：需要重构认证系统\n/virtual-intelligent-dev-team 重构认证系统，从 Session 改为 JWT\n```\n\n**会发生什么：**\n- 路由到 `Sentinel Architect`（高风险变更治理）\n- 激活 Pre-Development Planning Playbook\n- 生成 Planning Pack（包含阶段计划、通道笔记、进度锚点）\n- 提供多阶段执行路径和回滚点\n\n### 4. 产品定义（产品发现专家团）\n\n```bash\n# 场景：定义产品 PRD\n/virtual-intelligent-dev-team 帮我定义一个知识管理产品的 PRD\n```\n\n**会发生什么：**\n- 路由到 `World-Class Product Architect`\n- 激活 `product-discovery-council`（产品发现专家团）\n- 提供产品战略模板、用户研究模板、竞品分析模板\n- 生成结构化 PRD\n\n### 5. 自动化运行（显式 /auto）\n\n```bash\n# 场景：自动化执行多轮优化\n/virtual-intelligent-dev-team /auto 优化 API 响应时间\n```\n\n**会发生什么：**\n- 进入 Setup → Go 两阶段协议\n- 先建立 automation state（包含目标、检查点、恢复锚点）\n- 执行有边界的迭代优化\n- 保留状态文件供后续 resume\n\n---\n\n## 项目定位\n\n这个项目最适合三类问题：\n\n- 复杂研发交付\n - 例如小切片实现、大重构、迁移、跨模块联动、技术治理\n- 产品与研发协同\n - 例如需求澄清、验收标准、前后端协作、分轮 beta\n- 模糊想法分流\n - 例如用户只给出一个猜想，不确定该做产品验证、原型探索、技术可行性、架构风险还是交付拆解\n- 版本与闭环治理\n - 例如多轮优化、release gate、post-release feedback loop、resume\n\n## 为什么不是普通多专家提示词\n\n很多“虚拟团队”方案，主要解决的是“换几个角色来回答”。\n\n这个项目想解决得更深一层：\n\n- 不只换角色\n - 还要判断谁主负责、谁协同、是否需要治理\n- 不只给建议\n - 还要给出执行路径、恢复锚点和下一步\n- 不只做开发前\n - 还覆盖 beta、release、post-release feedback\n- 不只做单轮问答\n - 还支持有边界的多轮优化和状态恢复\n\n所以它更像一个“复杂软件工作的闭环协调层”，而不是一个“多身份回答器”。\n\n## 适合解决什么问题\n\n- 复杂研发任务的 lead agent 路由与协同\n- 模糊猜想的意图确认反问：先让用户在 `product-opportunity`、`prototype-exploration`、`technical-feasibility`、`architecture-risk`、`delivery-plan` 中确认方向，确认后才把 provisional route 收敛成最终路线\n- 大型重构、迁移、拆分、技术治理\n- 多轮优化、benchmark、回滚、resume\n- 产品定义、验收标准、分轮 beta 内测\n- 产品发现专家团与原型设计专家团：在 `product-spec-deliver` 内按需展开阶段内 specialists，但不替换顶层 lead\n- release gate 与 post-release feedback loop\n- 完成证据门禁：`done / ready / ship / handoff` 之前必须有结构化 completion evidence，且 `evidence_refs` 要能指向可验证命令或本地 artifact\n- trigger health 与 workflow quality baseline，避免该触发不触发、误触发、过度流程化或 completion claim 证据不足\n- goal framing：对宽目标、重复失败、release、beta、multi-agent 等任务先锁定 success evidence、stop condition 和 non-goals\n- anti-entropy governance：对 fallback growth、duplicate owner、adapter / guard 膨胀、delete vs compat 和 source-of-truth 删除边界做治理\n- 显式 `/auto` 自动运行与状态优先恢复\n- Team Engine Lite 的 Worker / Verifier 分离、RemediationPatch 和 DeliveryCycleReport\n- 受控真实 Subagent runtime eligibility：显式 multi-agent/subagent 请求或合格 `/auto` 工作流可生成 `SubagentRuntimePlan`；请求候选上限与宿主原子能力链共同决定 runtime tier，任一能力缺失都会 fail closed 到更低层级\n- 文件交接与完成证据：WorkOrder、ImplementationOutput、VerificationReport、RemediationPatch、DeliveryCycleReport 必须落到可校验文件；路径身份、角色方向、带时区时间戳和 schema 任一不符都会阻断验收\n- 结构化 Response Pack：Markdown 与 JSON sidecar 同步生成，scope boundary、runtime evidence、Team Engine 与 resume 信息可直接被 benchmark、automation 和 release gate 消费\n\n## 核心能力\n\n- `默认手动模式`\n - 默认是人工驱动模式，不会擅自进入自动运行。\n- `显式 /auto`\n - 只有显式输入 `/auto` 才会进入自动运行分支。\n- `setup -> go`\n - 自动运行保持两阶段协议，先建状态，再执行。\n- `safe / background / resume`\n - 自动子协议支持安全预演、后台执行、状态恢复。\n- `状态优先恢复`\n - 恢复优先读取机器可读的 automation state，而不是靠对话猜测上下文。\n- `小切片交付`\n - 小型功能或 bugfix 默认保留 quick slice brief、project context、delivery status 和验证证据。\n- `意图确认`\n - 低信息量或模糊猜想不会直接硬路由，会先给出目标 lead / workflow bundle / stage council 选项，让用户确认切入方向。\n- `目标边界`\n - 对容易漂移的任务先形成 goal frame，明确 success evidence、stop condition、non-goals 和当前 stop state。\n- `工作流质量基线`\n - 用 trigger accuracy、fast-path cheapness、output compactness、evidence freshness、artifact laziness 和 authority boundary 约束 skill 迭代。\n- `反熵治理`\n - 遇到 duplicate owner、fallback、adapter、guard 或兼容路径增长时，先判断旧路径该删除、保留兼容，还是需要用户确认。\n- `Team Engine Lite`\n - 作为 Delivery closure 内的交付子图，为 code-facing、release-facing、Git-facing 与 remediation 路线保留 Worker / Verifier 分离、max-cycle retry、RemediationPatch 和 DeliveryCycleReport。\n- `受控真实 Subagent runtime eligibility`\n - 显式 multi-agent / subagent / parallel agent 请求会生成受控计划、角色边界、spawn policy、merge policy 和 fallback；`spawn / wait / merge` 或 `create_session / kill_session / restart_session` 必须完整成链，且不得超过请求候选上限，否则自动降级。\n- `外部 Agent 后端软编排`\n - 可以把 Codex / Claude Code / OpenCode 当作角色后端，但默认只声明 `soft_orchestration_only`，不虚假声称真实异步多进程 runtime。\n- `有边界的迭代优化`\n - 优化循环是有边界、有证据、有回滚点的，不做无限自转。\n- `完成证据门禁`\n - 非平凡完成声明必须保留 action、result、covered scope、uncovered scope、residual risk、confidence grade 和 evidence refs；release gate 会拒绝只有 benchmark 绿、但缺少完成证据的 `ship`。\n- `发布与反馈闭环`\n - 不只做发布前 gate，也覆盖发布后的反馈回写与下一轮修复入口。\n- `阶段专家团`\n - 产品战略、PRD、用户研究、竞品、指标、路线图等请求可激活 `product-discovery-council`；高保真原型、设计系统、可运行 HTML 原型与可访问性审查可激活 `prototype-design-council`。两者都是 `World-Class Product Architect` 下面的 overlay，不会把简单任务升级成新顶层团队。\n- `Harness 工程约束门禁`\n - 6 个 code-facing bundle（plan-first-build / product-spec-deliver / audit-fix-deliver / govern-change-safely / root-cause-remediate / direct-execution）执行前必须创建 `.vidt/harness/engineering-constraints.md`，含 Scope / Non-Negotiable Constraints / Forbidden Changes / Verification Evidence / Rollback And Stop Conditions 五个必填章节，把\"实现前先约束\"变成硬门禁。\n- `Team Engine Lite 对抗式验收`\n - Worker 只产不验、Verifier 只验不产、Lead 只能基于 DeliveryCycleReport 接受；14 个合法状态（含 `spec_violation / human_resolved / resumed`）+ 5 个标准对象（WorkOrder / ImplementationOutput / VerificationReport / RemediationPatch / DeliveryCycleReport）；3 级 runtime claim（real_subagent_runtime / single_backend_multi_session / soft_orchestration_only）禁止把角色扮演误称为真实多 Agent runtime。\n- `Fail-closed 证据链`\n - breaker、Verifier、file handoff、Team Engine drill 和 stress gate 默认拒绝不完整或不可重放的证据；Response Pack sidecar 固化 scope boundary、runtime evidence、covered / uncovered scope 与 residual risk。\n- `Anti-Entropy 反熵治理`\n - 遇到 duplicate owner、fallback、adapter、guard 或兼容路径增长时，先分类（code-retirement / contract-carrying-code / derived-state / persistent-state），再选路径（delete-first / compat-exception / confirmation-first），未知依赖不等于活跃依赖证据。\n- `Self-Optimization 自优化循环`\n - bounded iteration + mutation catalog + offline loop drill：可对自身的 `routing-rules.json` / `regression-cases.json` / `evals.json` 做 JSON-aware 确定性自优化；live ≤3 轮、offline ≤120 轮、same-hypothesis ≤2 次重试；`rollback / keep / pivot / resume / hold→bootstrap→auto-run` 路径均可离线 drill 验证。\n\n## 能力矩阵\n\n| 维度 | 本项目提供什么 | 普通多专家提示词常见缺口 |\n| --- | --- | --- |\n| 任务路由 | 选择主负责人、协同者、治理轨道 | 往往只是平铺多个角色视角 |\n| 日常交付 | 小切片 brief、项目上下文、状态锚点 | 容易直接跳到实现，缺少可恢复上下文 |\n| 执行模式 | 支持手动模式与显式 `/auto` | 通常没有明确模式切换 |\n| 恢复能力 | 状态优先恢复、resume、恢复锚点 | 容易依赖上下文记忆 |\n| 迭代能力 | 有边界的多轮优化、基线、回滚决策 | 常见问题是无限\"再来一轮\" |\n| 发布治理 | release gate、completion evidence、hold 后续修复入口 | 常停留在\"建议发/不发\"或只看 benchmark 结果 |\n| 上线后闭环 | post-release feedback loop | 很少覆盖上线后的反馈回写 |\n| 产品协同 | 支持产品、研发、技术治理联动 | 容易偏单一研发视角 |\n| 阶段专家团 | 产品发现与原型设计可按需展开 council overlay | 常见做法要么单专家过载，要么所有任务都进重流程 |\n| Beta 验证 | 分轮内测、模拟用户、cohort ramp、反馈门禁 | 通常只有静态测试计划，没有结构化分轮验证 |\n| 工作流质量 | 触发健康、快路径廉价、证据新鲜度、artifact 懒创建、authority boundary | 容易越改越重，或把方法建议误说成最终权威 |\n| Subagent runtime | 请求候选上限 + 六项原子能力证据 + smoke test 共同决定三级 runtime，缺一即降级 | 容易把单个能力标志或角色扮演误称为真实多 Agent runtime |\n| 离线验证 | offline loop drill 验证回滚与恢复路径 | 很少验证关键闭环路径是否真的跑通 |\n| 工程约束门禁 | code-facing bundle 执行前必须创建 `.vidt/harness/engineering-constraints.md`，含 5 个必填章节 | 通常直接进入实现，缺少前置约束门禁 |\n| 对抗式验收 | Worker/Verifier/Lead 分离 + DeliveryCycleReport + 14 状态机 + `spec_violation` | 自产自审，或把角色扮演误称为真实多 Agent runtime |\n| 证据链 | 精确 file handoff + schema 校验 + Response Pack JSON sidecar + fail-closed gate | 证据靠自然语言转述，无法稳定重放或被下游消费 |\n| 反熵治理 | delete-first / compat-exception / confirmation-first 三路径决策 + 4 类目标分类 | 不断加 fallback 或 guard，旧路径永不退休 |\n| 自优化循环 | bounded iteration + mutation catalog + offline drill，可对自身 routing/evals 做确定性自优化 | 无自优化能力，或陷入\"再来一轮\"的无限自转 |\n\n## 快速开始\n\n如果你第一次使用，建议从这三种方式开始：\n\n```text\n$virtual-intelligent-dev-team 帮我接管这次重构，并给出可执行分工。\n$virtual-intelligent-dev-team /auto setup 这个项目级迁移。\n$virtual-intelligent-dev-team 判断当前版本是否可以 release。\n```\n\n对应的理解方式是：\n\n- 不带 `/auto`\n - 走手动模式，适合高风险任务和需要逐轮确认的场景\n- 带 `/auto setup`\n - 先建立自动化状态和恢复锚点\n- 再执行 `/auto go`\n - 进入自动执行阶段\n\n## 适合与不适合\n\n更适合：\n\n- 复杂研发任务\n- 跨产品与研发的交付协同\n- 需要多轮优化、恢复和发布治理的工作\n\n不太适合：\n\n- 纯商业战略\n- 融资、定价、泛咨询\n- 非软件交付型的轻量一次性问题\n\n## 目录结构\n\n```text\nvirtual-intelligent-dev-team/\n├── SKILL.md\n├── README.md\n├── VERSION\n├── LICENSE\n├── agents/\n├── assets/\n├── docs/\n├── evals/\n├── references/\n├── scripts/\n└── tests/\n```\n\n目录职责分层：\n\n- `SKILL.md`\n - 运行时契约、触发边界、主流程\n- `docs/`\n - 面向维护者与开源使用者的说明文档\n- `references/`\n - 路由规则、playbook、schema、真源细则\n- `assets/`\n - 模板、样例、卡片\n- `scripts/`\n - 校验、导出、自动运行、恢复、发布辅助脚本\n- `tests/`\n - 语义回归与契约测试\n\n## 快速入口\n\n- 使用说明：\n - [docs/usage-guide.md](docs/usage-guide.md)\n- 设计理念：\n - [docs/design-philosophy.md](docs/design-philosophy.md)\n- 文档索引：\n - [docs/README.md](docs/README.md)\n- 端到端示例：\n - [assets/end-to-end-example.md](assets/end-to-end-example.md)\n\n如果你想先上手：\n\n- 读 `README.md`\n- 再读 `docs/usage-guide.md`\n\n如果你想先理解设计：\n\n- 读 `docs/design-philosophy.md`\n- 再读 `SKILL.md`\n\n## 运行流程图\n\n```mermaid\nflowchart TD\n A[收到复杂软件任务] --> B{是否显式输入 /auto}\n B -->|否| C[手动模式]\n B -->|是| D[\"/auto setup\"]\n D --> E[建立 automation state]\n E --> F[\"/auto go 或 resume\"]\n F --> G[自动执行入口]\n\n C --> H[识别任务类型 / 风险 / 技术栈 / Git 与 process 信号]\n G --> H\n\n H --> I{是否大型改造 / 迁移 / 先规划}\n I -->|是| J[\"plan-first-build 前置规划和 progress anchor\"]\n J --> H\n I -->|否| K{是否窄实现或 bugfix}\n K -->|是| L[quick-slice-deliver]\n K -->|否| M[选择一个 lead agent]\n\n M --> N{是否需要 assistant / governance / Git guardrail}\n N -->|是| O[加载协同治理或 Git 轨道]\n N -->|否| P[保持轻量路由]\n O --> Q{选择最小 workflow bundle}\n P --> Q\n L --> Q\n\n Q -->|产品定义到交付| R[product-spec-deliver]\n Q -->|多轮优化或候选比较| S[bounded iteration]\n Q -->|反复失败或根因排查| T[root-cause-remediate]\n Q -->|分轮内测或用户递增| U[beta-feedback-ramp]\n Q -->|发版提交或正式验收| V[ship-hold-remediate]\n Q -->|已发布反馈回流| W[post-release-close-loop]\n Q -->|审计后修复| X[audit-fix-deliver]\n Q -->|发布安全回滚分支策略| Y[govern-change-safely]\n Q -->|AGENTS 或项目知识沉淀| Z[capture-project-knowledge]\n Q -->|常规复杂任务| AA[统一执行与验证]\n\n R --> AB{是否面向 code release Git remediation}\n S --> AB\n T --> AB\n U --> AB\n V --> AC{release gate 结论}\n W --> AB\n X --> AB\n Y --> AB\n AA --> AB\n Z --> AK[统一输出 + evidence + next step + resume anchor]\n\n AC -->|ship| W\n AC -->|hold| AD[生成 remediation brief 或 next iteration brief]\n AD --> AB\n\n AB -->|是| AE[Harness constraint gate]\n AE --> AF[Team Engine Lite]\n AF --> AG[DeliveryCycleReport]\n AG --> AH{Verifier verdict}\n AH -->|pass| AK\n AH -->|fail| AI[RemediationPatch 加有界重试]\n AI --> AF\n AH -->|hold| AJ[升级给 Lead 或 Human 决策]\n AJ --> AK\n\n AB -->|否| AK\n```\n\n**流程图与四大工程化支柱的映射**：\n\n- **Harness 工程约束门禁** → `AE` 节点：code-facing bundle 进入实现前必须经过此门禁\n- **Team Engine Lite 对抗式验收** → `AF` / `AG` / `AH` / `AI` 节点：Worker 产出 → Verifier 验收 → Lead 基于 DeliveryCycleReport 接受\n- **Anti-Entropy 反熵治理** → 贯穿 `N` / `O` 节点：加载协同治理轨道时触发 delete-first / compat-exception / confirmation-first 路径选择\n- **Self-Optimization 自优化循环** → `AI` 节点的\"有界重试\"体现了 bounded iteration 原则；skill 自身的 routing/evals 优化通过 offline loop drill 离线执行，不在此用户任务流程图中\n\n## 如何调用\n\n最常见的调用方式：\n\n```text\n$virtual-intelligent-dev-team 帮我接管这次重构，并给出可执行分工。\n$virtual-intelligent-dev-team /auto setup 这个项目级迁移。\n$virtual-intelligent-dev-team 判断当前版本是否可以 release。\n```\n\n如果你主要关心运行时规则，优先读：\n\n- `SKILL.md`\n- `references/playbook-index.md`\n- `references/tooling-command-index.md`\n\n如果你主要关心维护和扩展，优先读：\n\n- `README.md`\n- `docs/README.md`\n\n## 校验命令\n\n项目级：\n\n```bash\npython3 validate.py --changed\n```\n\nskill 级：\n\n```bash\npython3 ../scripts/sync_virtual_intelligent_dev_team_version.py --check\npython3 ../scripts/sync_virtual_intelligent_dev_team_version.py\npython3 skill-forge/scripts/quick_validate.py ./virtual-intelligent-dev-team\npython3 -m unittest virtual-intelligent-dev-team.tests.test_routing_and_guardrails\npython3 virtual-intelligent-dev-team/scripts/validate_virtual_team.py --pretty\n```\n\n## 版本\n\n当前版本见 [VERSION](VERSION)。\n\n## 致谢与参考来源\n\n本项目的迭代优化模式部分参考了 [agency-agents](https://github.com/msitarzewski/agency-agents) 的设计思路，并在其基础上适配了本 skill 的闭环工作流、状态恢复与发布治理等能力。\n\n相关的模式提炼见 [references/bounded-iteration-patterns.md](references/bounded-iteration-patterns.md)。\n\n## License\n\n本项目使用 [MIT License](LICENSE)。\n\nFile v0.1.2:_meta.json\n\n{\n \"ownerId\": \"kn73qh82zhjckby6wqrhe3ax2n80ckax\",\n \"slug\": \"virtual-intelligent-dev-team\",\n \"version\": \"0.1.2\",\n \"publishedAt\": 1786175164117\n}\n\nFile v0.1.2:references/agent-catalog.md\n\n# Agent Catalog\n\nSource of truth for each team member's scope, trigger patterns, and anti-patterns.\n\n## 1. Java Virtuoso\n\n- Core strengths: Java 21, Spring Boot 3.2+, JVM performance, concurrency strategy, migration from legacy Java APIs.\n- Best triggers: `java`, `spring`, `jvm`, `gc`, `virtual threads`, `java upgrade`, `spring boot`.\n- Typical tasks: backend implementation, performance tuning, Java refactors, Spring architecture, concurrency reviews.\n- Avoid using as lead for: pure business strategy, pure UI design, generic Git-only tasks.\n- Output bias: concrete Java decisions, production-ready implementation guidance, test strategy, migration notes.\n- Constraints: 禁止建议 `java.util.Date`，统一使用 `java.time`；`Stream.parallel()` 改动必须附性能基准；公共 API 变更必须同时更新 OpenAPI 契约与回归测试；JVM 调优建议必须标注 GC 算法与目标停顿时间。\n- Evidence requirements: 改动必须附 JVM 启动参数与运行时版本、受影响模块的回归测试结果；涉及启动耗时或吞吐时附 Spring Boot 启动基准。\n\n## 2. Sentinel Architect (NB)\n\n- Core strengths: high-risk change governance, staged execution, research-first delivery, safety rails for critical work.\n- Best triggers: `high risk`, `critical`, `production-impacting`, `research first`, `migration with rollback`, `sensitive refactor`.\n- Typical tasks: risky refactors, hotfix governance, phased modernization, conflict-heavy coordination.\n- Avoid using as lead for: low-risk one-off fixes or straightforward single-step answers.\n- Output bias: execution mode, risk gates, rollback thinking, decision checkpoints, auditability.\n- Constraints: 不得跳过风险评估直接进入执行；不得在没有回滚方案的情况下推进生产高风险变更；不得在反复失败场景下继续猜测，必须转入根因排查；重大变更必须保留人工 sign-off 节点。\n- Evidence requirements: 高风险变更需提供风险矩阵（影响面 / 回滚成本 / 监控信号）、分阶段执行计划与决策检查点、回滚策略与触发条件、上线前 checklist 与责任分工。\n\n## 3. Technical Trinity\n\n- Core strengths: general backend engineering, system design, implementation tradeoffs, reliability, DevSecOps-aware delivery.\n- Best triggers: `system design`, `backend`, `api`, `service`, `python`, `go`, `node`, `rust`, `architecture`, `reliability`.\n- Typical tasks: service design, module refactors, platform engineering, implementation planning, technical landing.\n- Avoid using as lead for: pure market strategy, pricing, financing, or purely visual frontend redesign.\n- Output bias: architecture choices, implementation slices, risk tradeoffs, operational concerns.\n- Constraints: 架构变更必须给出模块/接口/边界影响范围；多语言实现建议必须落到 `language-profiles.yaml` 已注册的 profile；迁移与重构必须保留行为对等的回归证据；禁止把业务战略 / 融资 / 定价类请求路由到本 Agent。\n- Evidence requirements: 通用工程任务需提供目标语言对应的 lint / test / build 命令（来自 `language-profiles.yaml`）、接口契约与现有调用方清单、回归测试结果或可运行验证脚本；架构改造场景额外需要模块地图或调用链证据。\n\n## 4. Code Audit Council\n\n- Core strengths: review, audit, security assessment, maintainability analysis, refactor prioritization.\n- Best triggers: `review`, `audit`, `security review`, `pr review`, `code review`, `vulnerability`, `refactor assessment`.\n- Typical tasks: bug/risk finding, PR review, hardening advice, quality grading, remediation prioritization.\n- Avoid using as lead for: requests without code context or pure strategy discussions.\n- Output bias: findings first, severity ordering, behavioral regressions, test gaps, concrete remediation advice.\n- Constraints: 审查意见必须按严重度（P0/P1/P2）排序；必须区分 UI/UX 审查与代码/安全审查；禁止把业务战略类讨论归入审查范围；每条 finding 必须给出修复建议或建议的修复路径。\n- Evidence requirements: 每条 finding 需附受影响文件/模块清单、严重度判定依据（安全影响 / 可维护性 / 行为差异）、建议的修复 patch 或步骤；P0 finding 必须给出阻断合并的判断与依据。\n\n## 5. Git Workflow Guardian\n\n- Core strengths: branch policy, staged Git workflow, commit/push/PR safety, merge/rebase handling, worktree usage.\n- Best triggers: `git workflow`, `commit`, `push`, `pull request`, `branch`, `rebase`, `merge`, `worktree`, `release`.\n- Typical tasks: safe Git execution, PR flow design, branch strategy, conflict handling, release hygiene.\n- Avoid using as lead for: pure code review or non-Git business discussions.\n- Output bias: safest next Git step, stage status, guardrails, branch/commit/PR recommendations.\n- Constraints: 禁止直接推送到 `main` / `master` 等受保护分支；禁止跳过 PR 流程直接合并；冲突处理必须先 rebase 后 merge，不允许无视冲突直接 push；敏感操作（force push / 强制覆盖 / 删除远端分支）必须二次确认。\n- Evidence requirements: Git 操作需附当前分支状态（status / ahead-behind）、PR / MR 链接或编号、CI / lint / test 通过状态；涉及 worktree 时附 worktree 路径与隔离分支清单。\n\n## 6. World-Class Product Architect\n\n- Core strengths: product definition, UX architecture, acceptance criteria, staged beta validation, cohort design, frontend interaction design, React implementation direction, design systems, accessibility.\n- Best triggers: `product brief`, `prd`, `acceptance criteria`, `user flow`, `scope`, `mvp`, `onboarding`, `beta`, `internal beta`, `user testing`, `cohort`, `ui`, `ux`, `react`, `next.js`, `dashboard`, `design system`, `tailwind`, `shadcn`, `accessibility`, `motion`.\n- Typical tasks: feature framing, redesigns, UI audits, responsive flows, acceptance criteria writing, staged beta plans, simulated-user profile design, user cohort simulation, session-trace review, form UX, component systems, frontend/backend interaction shaping.\n- Avoid using as lead for: pure backend infrastructure or pure business strategy.\n- Output bias: user flow clarity, scope boundary, acceptance criteria, beta-round gates, frontend implementation direction, interaction details, responsiveness, accessibility.\n- Constraints: PRD / 验收标准必须先于实现工作产出；涉及 UI/UX 时必须给出可访问性检查清单；涉及发布后反馈回流时必须绑定监控信号而不是主观判断；禁止把后端基础设施 / 纯业务战略作为本 Agent 主线。\n- Evidence requirements: 产品与前端任务需附用户流与验收标准、影响范围（界面 / 交互 / 设计系统 / 可访问性）；内测 / beta 场景额外附 cohort 定义与反馈门禁；发布后场景附监控信号或真实用户反馈样本。\n\n## Routing Guidance\n\n1. Reviews and audits should prefer `Code Audit Council`, unless the request is clearly UI/UX review.\n2. Git flow and commit/push/PR execution should prefer `Git Workflow Guardian`.\n3. Java and Spring requests should prefer `Java Virtuoso`.\n4. Product definition, acceptance criteria, UI/UX, and frontend-heavy work should prefer `World-Class Product Architect`.\n5. General implementation and backend design should prefer `Technical Trinity`.\n6. Add or elevate `Sentinel Architect (NB)` for high-risk or research-first work.\n\n## Stage Councils Under World-Class Product Architect\n\nStage councils are optional overlays. They do not become top-level leads.\n\n### `product-discovery-council`\n\n- Trigger signals: `产品战略`, `产品专家团`, `PRD`, `需求分析`, `用户研究`, `竞品`, `指标`, `路线图`, `sprint`, `stakeholder`, `product strategy`, `user research`, `competitive analysis`, `metrics`, `roadmap`.\n- Roles: `requirement-analyst`, `user-researcher`, `competitive-analyst`, `data-analyst`, `roadmap-planner`.\n- Output bias: accepted scope, P0/P1/P2, non-goals, user evidence, competitor or market proof, success metrics, roadmap sequencing.\n- Avoid using for: backend-only architecture, small implementation fixes, release-only or Git-only questions.\n\n### `prototype-design-council`\n\n- Trigger signals: `原型设计`, `设计原型`, `高保真`, `HTML 原型`, `设计系统`, `视觉设计`, `页面设计`, `品牌调性`, `prototype`, `high-fidelity`, `design system`, `visual design`, `accessibility`.\n- Roles: `ux-discovery`, `design-system-curator`, `prototype-builder`, `visual-critic`, `accessibility-reviewer`.\n- Output bias: design brief, design token choice, runnable prototype readiness, visual quality gate, accessibility gate.\n- Avoid using for: product strategy without UI surface, code-only refactors, or generic redesign requests that only need quick implementation.\n\n## 7. Data Pipeline Guardian\n\n- Core strengths: data pipeline architecture, ETL/ELT design, stream processing, data quality governance, schema evolution, data lineage, batch vs real-time tradeoffs, data warehouse/lake design, CDC (Change Data Capture), data observability.\n- Best triggers: `data pipeline`, `ETL`, `ELT`, `stream processing`, `kafka`, `spark`, `flink`, `airflow`, `dbt`, `data quality`, `data governance`, `schema evolution`, `CDC`, `data warehouse`, `data lake`, `data mesh`, `batch job`, `dataflow`, `pipeline orchestration`.\n- Typical tasks: pipeline architecture design, data quality rule implementation, schema migration strategies, stream vs batch decisions, data lineage tracking, pipeline monitoring and alerting, data contract definition.\n- Avoid using as lead for: pure business analytics without engineering context, simple one-off SQL queries without pipeline implications.\n- Output bias: pipeline topology decisions, data quality gates, schema contract enforcement, failure handling strategies, observability requirements.\n- Constraints: 数据管道变更必须评估对下游消费者的影响；schema 变更必须遵循向后兼容或显式迁移策略；数据质量问题必须分级（阻塞/告警/日志）并绑定处理策略；流处理场景必须明确 exactly-once/at-least-once 语义选择及其实现机制；禁止在没有数据血缘追踪的情况下推进复杂管道改造。\n- Evidence requirements: 管道设计需提供拓扑图（来源/转换/目标）、数据质量检查点与规则清单、schema 契约与版本策略、失败场景处理方案（重试/死信/告警）；涉及流处理时附语义保证机制与 checkpoint 策略；涉及 schema 变更时附向后兼容性分析与迁移步骤。\n\n## 8. API Contract Sentinel\n\n- Core strengths: API design governance, OpenAPI/AsyncAPI specification, contract-first development, backward compatibility enforcement, versioning strategies, API security, rate limiting, idempotency design, GraphQL schema governance, gRPC/protobuf contract management, contract lock co-signing.\n- Best triggers: `API design`, `API contract`, `OpenAPI`, `Swagger`, `AsyncAPI`, `REST API`, `GraphQL`, `gRPC`, `protobuf`, `API versioning`, `backward compatibility`, `breaking change`, `API gateway`, `rate limiting`, `idempotency`, `API security`, `contract-first`, `contract lock`, `contract-spec`.\n- Typical tasks: API contract review, breaking change detection, versioning strategy design, OpenAPI spec validation, GraphQL schema review, API security audit, rate limit and quota design, idempotency implementation guidance, contract-spec drafting and co-signing.\n- Avoid using as lead for: pure UI/UX design without API implications, internal-only private methods without contract concerns.\n- Output bias: contract clarity, backward compatibility preservation, versioning decisions, security considerations, client impact assessment, contract lock enforcement.\n- Constraints: API 变更必须评估对现有客户端的兼容性影响；breaking change 必须显式标记并给出迁移窗口或版本策略；公开 API 必须配套 OpenAPI/AsyncAPI 规范；API 安全审查必须覆盖认证/授权/输入验证/速率限制；GraphQL schema 变更必须评估查询复杂度与 N+1 风险；禁止在没有客户端影响分析的情况下推进 breaking change；涉及前后端协作的 WorkOrder 必须在实现前完成 contract-spec 共签（详见 `references/contract-lock-protocol.md`）；contract-spec 签署后不可单方面修改，修改需双方重新签署并递增版本号。\n- Evidence requirements: API 设计需提供 OpenAPI/AsyncAPI/GraphQL schema 规范、向后兼容性分析（字段变更/端点废弃/行为变更）、客户端影响清单（按调用方/使用频率/关键程度分级）、版本迁移计划与弃用时间表；涉及安全时附威胁模型与缓解措施；涉及性能时附速率限制策略与配额分配方案；涉及前后端协作时附已签署的 contract-spec 文件（含 endpoint/method/request_schema/response_schema/error_codes/version/signatures）。\n\nFile v0.1.2:references/anti-entropy-governance.md\n\n# Anti-Entropy Governance\n\nUse this reference when a change may add or retire paths, owners, fallbacks,\nadapters, guards, compatibility branches, or source-of-truth behavior.\n\nThe default preference is to reduce internal entropy. Do not preserve old paths\njust because they exist.\n\n## When To Activate\n\nActivate as a governance overlay when any of these appear:\n\n- duplicate owners\n- stale fallback branches\n- extra guard or adapter layers\n- local patches around a deeper owner problem\n- cleanup that may delete internal behavior\n- migration or compatibility work\n- schema, persistence, public API, or source-of-truth boundaries\n\nDo not activate for pure additive work with no retirement decision, tiny edits,\nor read-only Q&A.\n\n## Classification\n\nClassify the target before changing it:\n\n- `code-retirement`\n - internal source code, stale triggers, duplicate owners, dead fallbacks\n- `contract-carrying-code`\n - schemas, migrations, public APIs, host install or discovery behavior\n- `derived-state`\n - generated files, caches, rebuildable indexes\n- `persistent-state`\n - live database rows, uploaded source-of-truth files, identity, permission,\n billing, audit, queue, or non-rebuildable business data\n\n## Decision Paths\n\nChoose one:\n\n- `delete-first`\n - internal code retirement when no proven external dependency blocks removal\n- `compat-exception`\n - compatibility path remains because active external dependency evidence\n exists\n- `confirmation-first`\n - persistent-state or irreversible source-of-truth changes require scoped\n user confirmation before destructive execution\n\nUnknown dependency is not active dependency evidence.\n\n## Anti-Entropy Declaration\n\nBefore retiring or preserving a path, state:\n\n```yaml\nanti_entropy_declaration:\n deletion_class:\n old_path_or_object:\n new_canonical_owner:\n preserved_behavior:\n retired_behavior:\n external_boundary_touched:\n source_of_truth_data_risk:\n user_confirmation_required:\n```\n\nIf `user_confirmation_required: true`, stop destructive execution and ask for\nexplicit scoped confirmation.\n\n## Verification\n\nDo not verify only that tests are green. Verify that the owner and path shape\nare correct:\n\n- main-path check: new canonical owner carries the intended behavior\n- lingering-reference check: old path is gone or intentionally retained\n- negative check: retired behavior no longer activates\n- compatibility check: retained path has active dependency evidence\n- regression check: user-visible behavior remains within scope\n\n## Completion Closure\n\nWhen this overlay was active, completion output must include:\n\n- path chosen: `delete-first`, `compat-exception`, or `confirmation-first`\n- what was retired or preserved\n- evidence for owner correctness\n- remaining entropy or retirement follow-up\n\n## Data Channel Constraint\n\nKeep judgment in the LLM and data acquisition in scripts. The two must not be\nmixed in the same step.\n\nExternal data sources — issue trackers, doc platforms, design specs, API\ncontracts, dashboards — must be reached through dedicated script channels, not\nthrough a generic fetch primitive driven by the LLM. The LLM only reads the\nfile the script landed on disk.\n\nActivate this constraint when any of these appear:\n\n- a step needs content from a tool that offers a structured or scripted surface\n- the same data may be re-read across rounds or sessions\n- the evidence for a decision must be replayable or auditable\n\nRules:\n\n- one source, one channel: each external data source has a named script that\n fetches, normalizes, and writes a local file; the LLM consumes that file\n- no inline generic fetch: the LLM must not fetch arbitrary URLs to gather task\n inputs; route the fetch through the channel and read the result\n- land before deciding: the success signal of a long-running command is a file\n that exists on disk, not stdout; assert presence and then reason over the file\n- cite the file, not the fetch: when evidence is referenced, point at the landed\n artifact path so the same input can be re-read on resume\n\nThis keeps inputs deterministic and replayable. A resumed session reads the\nsame landed files instead of re-asking the LLM to re-derive what it fetched.\n\nFile v0.1.2:references/architecture-deepening-protocol.md\n\n# Architecture Deepening Protocol\n\nUse this micro-practice when the work is about architecture improvement,\ntestability, AI navigability, module ownership, adapters, seams, or entropy\nreduction.\n\n## Goal\n\nFind changes that make modules deeper: more useful behavior behind simpler,\nclearer interfaces. This gives maintainers locality and gives agents a smaller\nsurface to reason about.\n\n## Vocabulary\n\nUse these terms consistently:\n\n- `module`\n - Anything with an interface and implementation.\n- `interface`\n - Everything callers must know: types, invariants, ordering, errors, config,\n and behavior.\n- `implementation`\n - The code behind the interface.\n- `seam`\n - The place behavior can change without editing every caller.\n- `adapter`\n - A concrete implementation behind a seam.\n- `depth`\n - The leverage of the interface. Deep modules hide useful complexity behind a\n smaller interface.\n- `locality`\n - The degree to which bugs, changes, and knowledge stay concentrated.\n- `leverage`\n - The useful behavior callers get without learning internal complexity.\n\n## Evaluation Tests\n\nUse these before proposing a refactor:\n\n- `deletion test`\n - If deleting a module removes complexity entirely, it may be shallow. If the\n complexity reappears across many callers, the module may be earning its keep.\n- `adapter reality test`\n - One adapter can be a hypothetical seam. Two or more adapters prove a real\n seam.\n- `test surface test`\n - The interface should be the stable test surface; tests should not need\n private implementation knowledge.\n- `locality test`\n - A change should concentrate behavior rather than spread edits across many\n callers.\n\n## Candidate Shape\n\n```markdown\n## Deepening Candidate\n\n- Modules:\n- Current shallow interface:\n- Proposed deeper interface:\n- Locality gain:\n- Leverage gain:\n- Test surface:\n- Entropy retired:\n- Recommendation: Strong | Worth exploring | Speculative\n```\n\n## Relationship To Anti-Entropy\n\nUse `references/anti-entropy-governance.md` when the candidate retires duplicate\nowners, old paths, fallbacks, adapters, or source-of-truth behavior.\n\nDo not preserve a shallow path only because it already exists. Keep compatibility\nonly when active external dependency evidence exists.\n\n## Completion Evidence\n\nWhen active, completion should name:\n\n- candidates considered\n- top recommendation\n- deletion / adapter / locality evidence\n- tests that would become simpler or more reliable\n- entropy retired or deliberately preserved\n\nFile v0.1.2:references/auto-run-playbook.md\n\n# Auto Run Playbook\n\n`/auto` 是 `virtual-intelligent-dev-team` 的显式自动运行协议。\n\n默认仍然是手动模式。只有用户明确输入 `/auto`，才允许进入自动模式。\n\n## 1. 触发原则\n\n- `/auto`\n - 进入 `setup` 阶段\n - 只生成自动执行计划，不直接开跑\n- `/auto go`\n - 进入 `go` 阶段\n - 只在已存在 `.vidt/auto/auto-run-plan.json` 时允许继续\n- `/auto safe`\n - 保持两阶段协议\n - 把 stop cap 收紧到单次安全闭环\n- `/auto background`\n - 仍然走同步脚本\n - 但额外写 resumable state，供外层 detached / resume 协议消费\n- `/auto resume`\n - 优先吃最近一次 automation state 决策，再回退到最近一次 plan\n - 不绕过显式 `go`\n\n## 2. 当前白名单\n\n第一轮只开放三条 workflow：\n\n- `root-cause-remediate`\n- `ship-hold-remediate`\n- `post-release-close-loop`\n\n其他 workflow 即使用户写了 `/auto`，也仍然保持手动模式。\n\n## 3. 两阶段协议\n\n### `setup`\n\n目标：\n\n- 识别 workflow\n- 生成 `.vidt/auto/auto-run-plan.json`\n- 生成 `.vidt/auto/auto-run-plan.md`\n- 生成 `.vidt/auto/state/*.json`\n- 明确 stop cap、resume anchor、go command、安全护栏\n- 明确 `run_style / safety_level / resume_requested`\n\n### `go`\n\n目标：\n\n- 读取 setup 生成的 plan\n- 如果是 `resume`，优先尝试 state-first 恢复\n- 按 workflow 分派到底层脚本\n- 输出统一结果、恢复锚点和下一步\n- 写统一 automation state\n\n## 4. workflow 对应底层接线\n\n### `root-cause-remediate`\n\n- 初始化 `.vidt/iterations/`\n- 生成 `iteration-plan.auto.json`\n- 开启：\n - `autonomous_candidate_generation`\n - `auto_pivot_on_stagnation`\n- 调用：\n - `scripts/run_iteration_loop.py`\n\n### `ship-hold-remediate`\n\n- 调用：\n - `scripts/run_release_gate.py`\n- 默认带：\n - `--completion-evidence .vidt/evidence/completion-evidence.json`\n - `--auto-run-next-iteration-on-hold`\n- go 前应补全 `.vidt/evidence/completion-evidence.json`；否则 release gate 会按 `hold` 处理，而不是把 benchmark 全绿误判成 `ship`\n\n### `post-release-close-loop`\n\n- 初始化 `.vidt/post-release/`\n- 调用：\n - `scripts/evaluate_post_release_feedback.py`\n\n## 5. 安全护栏\n\n- 默认仍是 manual mode\n- `setup -> go` 必须分离\n- 不自动执行 destructive git\n- 必须先写 plan，再进入 go\n- 结果必须带 resume anchor\n- `background` 目前只定义 resumable contract，不启动 daemon\n- `safe` 会收紧 release hold 自动 remediation 与 iteration cap\n- `resume` 会优先暴露 state-driven decision card、恢复命令和 playbook\n- `go` 在 `resume_requested=true` 时，如果存在可执行 state decision，会先执行这条 state-first 路径\n\n## 6. 常用命令\n\n```bash\npython scripts/run_auto_workflow.py --text \"\" --mode setup --pretty\n```\n\n```bash\npython scripts/run_auto_workflow.py --mode go --plan .vidt/auto/auto-run-plan.json --pretty\n```\n\n产物补充：\n\n- `.vidt/auto/state/*.json`\n- `evals/release-gate/automation-state.json`\n- `.vidt/post-release/decisions/automation-state.json`\n\n恢复检查：\n\n```bash\npython scripts/inspect_automation_state.py --repo . --pretty\n```\n\n这个入口用来读取最近一次 machine-readable automation state，\n并给出当前最合适的恢复命令、恢复锚点，以及状态驱动的 playbook 决策。\n\n如果要把这个决策推进到真正执行：\n\n```bash\npython scripts/resume_from_automation_state.py --repo . --pretty\n```\n\n```bash\npython scripts/resume_from_automation_state.py --repo . --execute --pretty\n```\n\n- 默认仍然先 dry-run\n- 只有显式 `--execute` 才会执行恢复命令\n- 执行前会检查推荐命令是否命中受控 allowlist\n- 执行结果会写入 `.vidt/auto/resume-executions/`\n- 这个入口不会绕过 `/auto` 的 `setup -> go` 两阶段\n\nFile v0.1.2:references/automation-resume-decision-matrix.md\n\n# Automation Resume Decision Matrix\n\n这份矩阵定义 `inspect_automation_state.py` 如何把 machine-readable automation state 转成可执行恢复决策。\n\n目标不是只输出“最近一次状态文件”，而是直接回答：\n\n- 现在处于哪种恢复场景\n- 应该读哪份 playbook\n- 下一条最合适的命令是什么\n- 当前还卡着哪些阻塞条件\n\n## 1. `auto-run-setup`\n\n- 决策：`resume-explicit-go`\n- 含义：setup 已经完成，下一步进入显式 `go`\n- 默认命令：\n - `python scripts/run_auto_workflow.py --mode go --plan .vidt/auto/auto-run-plan.json --pretty`\n- 主要 playbook：\n - `references/auto-run-playbook.md`\n - 如果是根因链路，再加 `references/root-cause-escalation-playbook.md`\n - 如果是发布链路，再加 `references/release-gate-playbook.md`\n - 如果是发布后链路，再加 `references/post-release-feedback-playbook.md`\n\n## 2. `release-gate-result`\n\n### 当 `decision = ship`\n\n- 决策：`release-ship-continue-post-release`\n- 含义：发布门禁已通过，下一步进入 post-release feedback\n- 优先命令：\n - 使用 `follow_up.post_release_bootstrap.recommended_command`\n- 主要 playbook：\n - `references/release-gate-playbook.md`\n - `references/post-release-feedback-playbook.md`\n\n### 当 `decision = hold`\n\n- 决策：`release-hold-reopen-iteration`\n- 含义：发布仍被阻塞，下一步回到 bounded iteration / hold brief\n- 优先命令：\n - 使用 hold brief 里的第一条 `recommended_commands`\n- 主要 playbook：\n - `references/release-gate-playbook.md`\n - `references/iteration-protocol.md`\n\n## 3. `post-release-feedback-result`\n\n### 当 `decision = monitor`\n\n- 决策：`post-release-monitor-continue`\n- 含义：继续观察，不重新开 remediation\n- 主要 playbook：\n - `references/post-release-feedback-playbook.md`\n\n### 当 `decision = iterate`\n\n- 决策：`post-release-reopen-iteration`\n- 含义：真实线上反馈已触发 corrective slice\n- 主要 playbook：\n - `references/post-release-feedback-playbook.md`\n - `references/iteration-protocol.md`\n\n### 当 `decision = escalate`\n\n- 决策：`post-release-escalate-governance`\n- 含义：问题已经不是单纯产品修补，而是要进入治理升级\n- 主要 playbook：\n - `references/post-release-feedback-playbook.md`\n - `references/technical-governance-playbook.md`\n\n## 4. Guardrails\n\n- `inspect_automation_state.py` 优先读 companion result，而不是只看 state 顶层字段\n- 没有 companion result 时，才回退为通用恢复命令\n- `resume_from_automation_state.py` 只消费 `decision_card.recommended_command`\n- 默认先 dry-run，只有显式 `--execute` 才允许真正执行\n- 恢复执行必须命中受控 allowlist，不能把任意 shell 命令透传出去\n- 决策卡必须同时给出：\n - `decision_id`\n - `decision_label`\n - `decision_reason`\n - `resume_strategy`\n - `recommended_command`\n - `playbooks`\n - `blocking_conditions`\n\nFile v0.1.2:references/automation-resume-execution.schema.json\n\n{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"$id\": \"urn:skill-hub:virtual-intelligent-dev-team:automation-resume-execution\",\n \"title\": \"Automation Resume Execution\",\n \"type\": \"object\",\n \"required\": [\n \"schema_version\",\n \"generated_at\",\n \"resume_execution_id\",\n \"selected_state_path\",\n \"selection_mode\",\n \"decision_card\",\n \"recommended_command\",\n \"command_allowed\",\n \"allowed_script\",\n \"execution\"\n ],\n \"properties\": {\n \"schema_version\": {\n \"const\": \"automation-resume-execution/v1\"\n },\n \"generated_at\": {\n \"type\": \"string\"\n },\n \"resume_execution_id\": {\n \"type\": \"string\"\n },\n \"selected_state_path\": {\n \"type\": \"string\"\n },\n \"selection_mode\": {\n \"type\": \"string\"\n },\n \"decision_card\": {\n \"type\": \"object\",\n \"required\": [\n \"decision_id\",\n \"decision_label\",\n \"decision_reason\",\n \"resume_strategy\",\n \"recommended_command\",\n \"resume_anchor\",\n \"playbooks\",\n \"blocking_conditions\",\n \"handoff_target\",\n \"follow_up_artifacts\",\n \"companion_payload_path\"\n ],\n \"properties\": {\n \"decision_id\": {\n \"type\": \"string\"\n },\n \"decision_label\": {\n \"type\": \"string\"\n },\n \"decision_reason\": {\n \"type\": \"string\"\n },\n \"resume_strategy\": {\n \"type\": \"string\"\n },\n \"recommended_command\": {\n \"type\": \"string\"\n },\n \"resume_anchor\": {\n \"type\": \"string\"\n },\n \"playbooks\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"blocking_conditions\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"handoff_target\": {\n \"type\": \"string\"\n },\n \"follow_up_artifacts\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"companion_payload_path\": {\n \"type\": [\n \"string\",\n \"null\"\n ]\n }\n },\n \"additionalProperties\": false\n },\n \"recommended_command\": {\n \"type\": \"string\"\n },\n \"command_allowed\": {\n \"type\": \"boolean\"\n },\n \"allowed_script\": {\n \"type\": [\n \"string\",\n \"null\"\n ]\n },\n \"execution\": {\n \"type\": \"object\",\n \"required\": [\n \"executed\",\n \"returncode\",\n \"stdout\",\n \"stderr\"\n ],\n \"properties\": {\n \"executed\": {\n \"type\": \"boolean\"\n },\n \"command\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"returncode\": {\n \"type\": [\n \"integer\",\n \"null\"\n ]\n },\n \"stdout\": {\n \"type\": \"string\"\n },\n \"stderr\": {\n \"type\": \"string\"\n }\n },\n \"additionalProperties\": false\n }\n },\n \"additionalProperties\": false\n}\n\nFile v0.1.2:references/automation-state.schema.json\n\n{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"$id\": \"urn:skill-hub:virtual-intelligent-dev-team:automation-state.schema\",\n \"title\": \"Virtual Intelligent Dev Team Automation State\",\n \"type\": \"object\",\n \"required\": [\n \"schema_version\",\n \"generated_at\",\n \"run_id\",\n \"parent_run_id\",\n \"source_workflow\",\n \"state_kind\",\n \"mode\",\n \"phase\",\n \"status\",\n \"decision\",\n \"execution_mode\",\n \"run_style\",\n \"safety_level\",\n \"resume_requested\",\n \"detached_ready\",\n \"resume_anchor\",\n \"resume_artifacts\",\n \"recommended_next_step\",\n \"handoff_target\",\n \"state_paths\",\n \"upstream_dependencies\",\n \"notes\",\n \"metadata\"\n ],\n \"properties\": {\n \"schema_version\": {\n \"const\": \"automation-state/v1\"\n },\n \"generated_at\": {\n \"type\": \"string\"\n },\n \"run_id\": {\n \"type\": \"string\"\n },\n \"parent_run_id\": {\n \"type\": [\n \"string\",\n \"null\"\n ]\n },\n \"source_workflow\": {\n \"type\": \"string\"\n },\n \"state_kind\": {\n \"type\": \"string\"\n },\n \"mode\": {\n \"type\": \"string\"\n },\n \"phase\": {\n \"type\": \"string\"\n },\n \"status\": {\n \"type\": \"string\"\n },\n \"decision\": {\n \"type\": \"string\"\n },\n \"execution_mode\": {\n \"type\": [\n \"string\",\n \"null\"\n ]\n },\n \"run_style\": {\n \"enum\": [\n \"foreground\",\n \"background\"\n ]\n },\n \"safety_level\": {\n \"enum\": [\n \"standard\",\n \"safe\"\n ]\n },\n \"resume_requested\": {\n \"type\": \"boolean\"\n },\n \"detached_ready\": {\n \"type\": \"boolean\"\n },\n \"resume_anchor\": {\n \"type\": \"string\"\n },\n \"resume_artifacts\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"recommended_next_step\": {\n \"type\": \"string\"\n },\n \"handoff_target\": {\n \"type\": \"string\"\n },\n \"state_paths\": {\n \"type\": \"object\",\n \"required\": [\n \"primary\",\n \"related\"\n ],\n \"properties\": {\n \"primary\": {\n \"type\": \"string\"\n },\n \"related\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n }\n },\n \"additionalProperties\": false\n },\n \"upstream_dependencies\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"notes\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"string\"\n }\n },\n \"metadata\": {\n \"type\": \"object\"\n }\n },\n \"additionalProperties\": false\n}\n\nFile v0.1.2:references/baseline-registry.md\n\n# Baseline Registry\n\nBounded iteration needs a stable baseline reference before it can judge candidates.\n\n## Purpose\n\nThe baseline registry records local benchmark reports that can be reused across rounds.\n\n## Storage\n\n- default workspace: `.vidt/iterations/`\n- registry file: `.vidt/iterations/baselines/registry.json`\n- stored baseline report: `.vidt/iterations/baselines/