vibe-coding-master 0.3.32 → 0.4.1

package/docs/{v0.4-custom-workflow-plan.md → v0.5-custom-workflow-plan.md}

@@ -1,10 +1,14 @@
-# VCM 0.4 Custom Workflow Plan
+# VCM 0.5 Custom Workflow Plan
 
-Last updated: 2026-06-21
+Last updated: 2026-06-22
 
-This document defines the proposed VCM 0.4 custom workflow architecture.
+This plan was originally drafted as the VCM 0.4 custom workflow plan. It moved
+to VCM 0.5 when VCM 0.4 was narrowed to harness optimization, Harness Engineer,
+and Harness Studio.
 
-VCM 0.4 should turn the current fixed role chain into a configurable workflow
+This document defines the proposed VCM 0.5 custom workflow architecture.
+
+VCM 0.5 should turn the current fixed role chain into a configurable workflow
 system. Users should be able to compose the task process, edit role definitions,
 choose role runtime policies, and decide where gates, checks, and human review
 belong. The product should still feel like VCM: local, visible, recoverable, and
@@ -28,7 +32,7 @@ Some users need heavier architecture review. Some need a fast bug-fix workflow.
 Some need long-lived planning sessions. Some want fresh implementation sessions.
 Some want mandatory final gates only for high-risk tasks.
 
-VCM 0.4 should make these choices explicit and configurable without turning the
+VCM 0.5 should make these choices explicit and configurable without turning the
 app into a fragile scripting environment.
 
 The target outcome:
@@ -71,7 +75,7 @@ running when no workflow node is active.
 
 ## 3. Non-Goals
 
-VCM 0.4 should not:
+VCM 0.5 should not:
 
 - become a general BPMN engine
 - allow arbitrary untrusted code inside workflow definitions
@@ -212,7 +216,7 @@ Session lifecycle should be explicit per role:
 - `manual`: VCM prepares the role, but the user starts and drives it manually
 - `disabled`: the role exists in the template but is not active for this run
 
-This is one of the main 0.4 features. Different roles need different memory
+This is one of the main 0.5 features. Different roles need different memory
 and isolation tradeoffs:
 
 - PM usually benefits from task continuity.
@@ -573,7 +577,7 @@ Recommended safety defaults:
 
 ## 13. UI Design
 
-VCM 0.4 needs two UI layers:
+VCM 0.5 needs two UI layers:
 
 1. Running task view
 2. Workflow builder view
@@ -746,16 +750,16 @@ The following details should be decided before implementation:
 
 - exact workflow JSON schema
 - whether custom templates should support YAML in addition to JSON
-- how much graph editing belongs in 0.4 versus later versions
+- how much graph editing belongs in 0.5 versus later versions
 - final expression language for branch conditions
 - whether command nodes should use allowlisted command templates only
 - how workflow templates are imported, exported, and named
 - how to present workflow validation errors in the UI
 - how task creation should choose between default and custom workflow templates
 
-## 18. Recommended 0.4 Scope
+## 18. Recommended 0.5 Scope
 
-The strongest 0.4 scope is:
+The strongest 0.5 scope is:
 
 - workflow engine foundation
 - built-in default workflow expressed as data

package/docs/vcm-cc-best-practices.md

@@ -171,8 +171,8 @@ Current runtime files and directories:
 .ai/vcm/handoffs/known-issues.md
 .ai/vcm/gate-reviews/
 .ai/vcm/jobs/<job-id>/
+.ai/vcm/harness-engineer/session.json
 .ai/vcm/bootstrap/session.json
-.ai/vcm/bootstrap/bootstrap.log
 ```
 
 App-local VCM task records live outside the connected repository:
@@ -402,22 +402,17 @@ during bootstrap.
 Important claims should be marked as verified, inferred, unknown, or needing
 human confirmation.
 
-VCM should launch bootstrap as a visible temporary Claude Code terminal, not as
-an invisible background task:
+VCM should run bootstrap through the project-scoped `harness-engineer` session,
+not through a separate temporary terminal or invisible background task:
 
 - run the deterministic fixed installer first
-- start Claude Code in the connected repository root without a role agent
-- set `VCM_TASK_REPO_ROOT`, `VCM_HARNESS_BOOTSTRAP=1`, `VCM_SESSION_ID`, and
-  `VCM_API_URL`
+- start or resume the `harness-engineer` role in the connected repository root
 - send a prompt that explicitly requires using `vcm-harness-bootstrap`
-- log terminal output under `.ai/vcm/bootstrap/bootstrap.log`
-- persist session metadata under `.ai/vcm/bootstrap/session.json`
-- mark bootstrap complete only when project context, generated context,
-  project architecture docs, module architecture docs, and testing docs are
-  present and non-empty
+- persist the bootstrap run marker under `.ai/vcm/bootstrap/session.json`
+- mark the bootstrap run complete when the `harness-engineer` Stop hook arrives
 
 The UI should expose both stages: fixed install status and bootstrap completion
-status. A failed or disconnected bootstrap terminal should be restartable
+status. A failed or disconnected Harness Engineer session should be restartable
 without treating project-owned durable docs as VCM-owned harness files.
 
 ## 12. Final Acceptance

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vibe-coding-master",
-  "version": "0.3.32",
+  "version": "0.4.1",
   "description": "Local GUI session cockpit for Claude Code role sessions.",
   "type": "module",
   "files": [