vibe-coding-master 0.3.1 → 0.3.3

package/docs/codex-review-gates.md

@@ -123,6 +123,7 @@ Recommended inputs:
 - original user request
 - project-manager route message or durable task plan when present
 - architecture plan
+- Scaffold Manifest and any architect-created scaffold diff
 - relevant durable architecture docs
 - `docs/TESTING.md` when the plan depends on validation strategy
 - changed file list when architect created scaffolding
@@ -132,6 +133,8 @@ Codex should review whether:
 - the plan matches the user request
 - the architecture boundaries are clear and compatible with the existing repo
 - file responsibilities and public contracts are specific enough for coder
+- the Scaffold Manifest carries task-specific context and coder guidance instead
+  of putting that information in source-code comments
 - the plan avoids unnecessary scope expansion
 - risks, dependencies, migrations, permissions, data, and error paths are named
 - acceptance and validation evidence can be produced
@@ -215,6 +218,8 @@ Codex should review whether:
 - the final diff satisfies the user request
 - the implementation contains correctness bugs or behavior regressions
 - the code follows existing project conventions
+- source and test comments contain no task-specific process notes, phase notes,
+  current-task rationale, or coder instructions
 - tests and implementation remain aligned
 - durable docs and generated artifacts are consistent with the diff
 - files outside the expected scope are explained
@@ -300,11 +305,17 @@ Codex review outputs live under:
 .ai/vcm/codex-reviews/requests/<request-id>.json
 ```
 
-VCM owns `.ai/vcm/codex-reviews/index.json`. It records the enablement marker,
-active gate, gate status, report path, decision, input hash, execution error,
-skip / override reason, and timestamps. PM reads this state through VCM turn
-context or the `vcm-codex-review-gate` skill; PM must not infer Codex state from
-report files alone.
+VCM stores Codex Review Gate switches outside the repository in the global
+`~/.vcm/settings.json` file as one VCM-wide selected gate list. The
+project-local `.ai/codex/config.toml` must not store gate enablement, VCM must
+not key these switches by project or task, and VCM must not create a separate
+Codex review settings file for them.
+
+VCM owns `.ai/vcm/codex-reviews/index.json` as task runtime state. It mirrors
+the global settings enablement marker, active gate, gate status, report path,
+decision, input hash, execution error, skip / override reason, and timestamps.
+PM reads this state through VCM turn context or the `vcm-codex-review-gate`
+skill; PM must not infer Codex state from report files alone.
 
 The `.ai/codex/` directory is VCM-managed runtime configuration for the fifth
 role. It should contain:
@@ -336,11 +347,9 @@ The managed block should include the Codex reviewer role, evidence sources,
 three gate-specific review criteria, finding format, and write constraints.
 Project-local custom notes may live outside the block.
 
-`.ai/codex/config.toml` is VCM-owned launch configuration. Codex does not
-natively discover arbitrary `.ai/codex/config.toml` files the way it discovers
-`$CODEX_HOME/config.toml` or layered `$CODEX_HOME/<profile>.config.toml` files,
-so the VCM Codex adapter reads this file and maps supported keys to the Codex
-CLI invocation.
+`.ai/codex/config.toml` is stable VCM-owned Codex Reviewer permission
+configuration. It must not contain Codex Review Gate switches, default
+`command = "codex"` boilerplate, or model / effort values that the VCM UI owns.
 
 `.ai/codex/.codex/config.toml` and `.ai/codex/.codex/hooks.json` are the
 Codex CLI project-level hook configuration. Because VCM starts Codex with
@@ -375,6 +384,9 @@ root using a relative path:
 ".ai/codex" = "read"
 ".ai/vcm/codex-reviews" = "write"
 "**/*.env" = "deny"
+
+[permissions.vcm_codex_reviewer.network]
+enabled = true
 ```
 
 With `--cd <taskRepoRoot>/.ai/codex`, `../..` points back to
@@ -450,10 +462,16 @@ codex \
   --sandbox workspace-write \
   --ask-for-approval never \
   --dangerously-bypass-hook-trust \
-  --model <model-from-.ai/codex/config.toml> \
-  --config model_reasoning_effort="<effort-from-.ai/codex/config.toml>"
+  --search \
+  --model <model-selected-in-VCM-UI> \
+  --config model_reasoning_effort="<effort-selected-in-VCM-UI>"
 ```
 
+VCM omits `--model` or `model_reasoning_effort` when the user selects
+`Default`, letting Codex CLI use its account or CLI default. `--search` enables
+Codex CLI's native web search tool for reviewer checks that need current
+external context.
+
 Starting from `.ai/codex` causes Codex to load `.ai/codex/AGENTS.md` through
 its normal `AGENTS.md` discovery path and `.ai/codex/.codex/hooks.json` through
 the Codex project hook path. VCM sends the gate prompt into this terminal,
@@ -472,10 +490,11 @@ connected active task and contains three independent toggles:
 - Validation Adequacy
 - Final Diff
 
-All three toggles default to `off`. Turning on any gate writes it into
-`.ai/codex/config.toml` under `[vcm.codex_review].required_gates` and sets
-`enabled = true`. Turning all gates off writes `enabled = false` and
-`required_gates = []`.
+All three toggles default to `off`. Turning on any gate writes the selected
+global gate list to `~/.vcm/settings.json`. Turning all gates off stores an
+empty selected gate list. VCM then mirrors this global setting into the active
+task's `.ai/vcm/codex-reviews/index.json` as runtime state for PM/tool
+consumption.
 
 The task workspace must not show a separate Codex Review Gates panel. The UI
 does not expose manual `Run`, `Run Again`, `Retry`, `Skip`, or `Override`

package/docs/full-harness-baseline.md

@@ -81,7 +81,7 @@ These entries match the current `example/rust-layered/.ai/vcm-harness-manifest.j
 | Claude settings | `.claude/settings.json` | json-merge | Long-term | VCM owns hook entries matching VCM command markers. |
 | Agent directory | `.claude/agents/` | VCM-created directory | Long-term | Contains the four core VCM role agents. |
 | Core agent | `.claude/agents/project-manager.md` | managed-block | Long-term | Project-manager role rules. |
-| Core agent | `.claude/agents/architect.md` | managed-block | Long-term | Architect role rules: plan document, code scaffolding, Debug Mode, docs sync. |
+| Core agent | `.claude/agents/architect.md` | managed-block | Long-term | Architect role rules: plan document, Scaffold Manifest, code scaffolding, Debug Mode, docs sync. |
 | Core agent | `.claude/agents/coder.md` | managed-block | Long-term | Coder role rules: scaffold implementation, coding standards, baseline unit checks. |
 | Core agent | `.claude/agents/reviewer.md` | managed-block | Long-term | Reviewer role rules: independent validation, TESTING.md strategy, integration/E2E case lists. |
 | Skill directory | `.claude/skills/` | VCM-created directory | Conditional long-term | Keep while repo-local VCM skills are installed. |

package/docs/product-design.md

@@ -75,7 +75,7 @@ Recommended flow:
 
 ```text
 project-manager
-  -> architect architecture plan and code scaffolding
+  -> architect architecture plan, Scaffold Manifest, and code scaffolding
   -> coder implementation and baseline unit checks
   -> reviewer independent validation
   -> architect docs sync / architecture drift check
@@ -219,6 +219,7 @@ The project manager must not become the architect, coder, reviewer, or debugger
 The architect owns:
 
 - architecture plan
+- Scaffold Manifest for task-specific file context and coder guidance
 - module boundaries
 - file responsibilities
 - cross-file callable surfaces and contract comments

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

@@ -194,8 +194,9 @@ VCM uses four core roles:
 - `architect`: technical planner and docs-sync owner. It defines module/file
   responsibilities, cross-file callable surfaces, public contracts, phase
   boundaries, risks, and durable docs updates. Before coder work starts,
-  architect writes the plan and materializes it in code scaffolding with
-  contract comments and `VCM:CODE` placeholders.
+  architect writes the plan with a Scaffold Manifest and materializes only the
+  minimum necessary code scaffolding with durable contract comments and
+  `VCM:CODE` placeholders.
 - `coder`: implementation owner. It changes production code and baseline unit
   tests within the approved plan. It follows the architect-defined scaffold,
   implements and removes `VCM:CODE` placeholders, follows general coding
@@ -240,19 +241,28 @@ workload or context size is not a valid reason to change the architect plan.
 ## 7.1 Architecture Plan And Code Scaffolding
 
 For code changes, the architect plan is not only a markdown handoff. It is a
-plan document plus code scaffolding.
+plan document plus a Scaffold Manifest and the minimum necessary code
+scaffolding.
 
 The plan document defines affected modules, changed or created files, file
 responsibilities, why each file is in scope, user-visible behavior changes,
 non-private cross-file callable surfaces, docs impact, risks, and Replan
 triggers.
 
+The Scaffold Manifest carries task-specific file context for the current handoff:
+why a file is in scope, what coder should implement, allowed implementation
+freedom, expected `VCM:CODE` placeholders, durable code comment needs, proof
+points, and Replan triggers. Task context, phase notes, handoff instructions,
+temporary rationale, and coder guidance belong in the Scaffold Manifest, not in
+source-code comments.
+
 Code scaffolding materializes that plan in the repository before coder work
 starts:
 
 - new modules or files are created when needed
-- file-level responsibilities, logic boundaries, collaborators, and non-goals
-  are documented in code
+- durable behavior, contracts, invariants, error boundaries, or non-obvious
+  logic are documented in code only when they should remain useful after the
+  task is complete
 - new or changed non-private callable surfaces are defined directly in code with
   signature shape and contract comments
 - incomplete implementation bodies are marked with `VCM:CODE`

package/package.json

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