vibe-coding-master 0.6.9 → 0.6.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/backend/templates/harness/architect-agent.js +3 -1
- package/dist/backend/templates/harness/project-manager-agent.js +11 -0
- package/dist-frontend/assets/{index-BPUcpt21.js → index-DIfaGVNJ.js} +23 -23
- package/dist-frontend/index.html +1 -1
- package/package.json +1 -1
- package/scripts/harness-tools/generate-module-index +13 -8
|
@@ -68,8 +68,10 @@ export function renderArchitectHarnessRules() {
|
|
|
68
68
|
- Remove temporary diagnostics before completion.
|
|
69
69
|
- If the fix exceeds those limits, return a normal architecture plan with root cause, evidence, affected scope, and Replan triggers.
|
|
70
70
|
- Architect-run validation in Debug Mode is diagnostic evidence, not final acceptance.
|
|
71
|
+
- Before handing off an architect-completed Debug Mode fix, run the smallest relevant L0 fast checks for the touched files or changed modules: format, lint, typecheck, boundary, dependency, or project-defined equivalents. If a check cannot run, report the exact reason.
|
|
72
|
+
- If the Debug Mode fix changes module structure, source/test file lists, public APIs, routes, exports, re-exports, or other externally consumed surface, run \`.ai/tools/generate-module-index\` / \`.ai/tools/generate-public-surface\` or their \`--check\` mode as applicable.
|
|
71
73
|
- After an architect-completed debug fix, route to reviewer for independent final validation before project-manager final acceptance.
|
|
72
|
-
- Report root cause, changed files, production-code changed line count, validation run, and final disposition.
|
|
74
|
+
- Report root cause, changed files, production-code changed line count, L0 checks run or skipped with reason, generated-context regeneration or freshness check when applicable, diagnostic validation run, and final disposition.
|
|
73
75
|
|
|
74
76
|
### Replan And Drift
|
|
75
77
|
|
|
@@ -17,6 +17,17 @@ export function renderProjectManagerHarnessRules() {
|
|
|
17
17
|
- Do not overload the user with file names, function names, logs, or implementation details unless they are necessary for the user's decision.
|
|
18
18
|
- Do not oversimplify findings. Preserve the cause, impact, risk, and required next step so the user can understand why the flow is blocked or why approval is needed.
|
|
19
19
|
|
|
20
|
+
### PM Managed Mode
|
|
21
|
+
|
|
22
|
+
PM Managed Mode applies only when the user explicitly asks to complete the current task in this mode.
|
|
23
|
+
|
|
24
|
+
- PM must drive the task to completion according to the user's request.
|
|
25
|
+
- PM must not delay, narrow, reinterpret, skip, or deviate from the requested task without explicit user approval.
|
|
26
|
+
- Questions about how to complete the task are managed inside the VCM flow. This includes workload, phasing, implementation approach, module boundaries, dependencies, internal services, permissions, validation, debugging, replanning, and review fixes.
|
|
27
|
+
- Simple or technical execution questions should be routed to Architect or the responsible role for decision.
|
|
28
|
+
- Ask the user only when the task cannot proceed without user intent or real-world authorization: unclear or conflicting requirements, required external accounts/secrets/test environments/data access, real cost, production permission, sensitive data access, durable-doc conflict, or a proven need to change the requested outcome.
|
|
29
|
+
- When PM asks the user, the flow must stop and wait for the user's explicit instruction before continuing.
|
|
30
|
+
|
|
20
31
|
### Routing
|
|
21
32
|
|
|
22
33
|
- Use the routes defined in \`CLAUDE.md\`.
|