Vibe Coding Production Kit v0.9.3

Highlights

Evidence-backed control plane hardening

The candidate accumulates the completed post-v0.9.2 control-plane stages:

• bounded Git-aware fresh review and Source-of-Truth freshness;
• verification provenance and workspace/monorepo semantics;
• project-sensitive security profiles;
• deterministic prompt behavioral evaluation;
• explicit architecture fitness functions;
• release-candidate automation with retained exact-revision evidence;
• deterministic local community profile/plugin loading with explicit digest pins and capability grants.

Release automation without automatic approval

Stage 9 adds vcp release-check <version>.

Preview mode checks static release contracts without running npm packaging/publish-dry-run/install/update mechanics.

Run mode may execute:

• npm pack --json;
• npm publish --dry-run --json;
• local install smoke from the generated tarball;
• a local lifecycle smoke starting from the retained previous release tag;
• post-update framework/Doctor/idempotence checks.

It never executes:

• npm publish;
• tag creation, movement, deletion, or recreation;
• GitHub release creation;
• deployment.

A green report means the declared candidate mechanics passed. Actual publication and immutable tag creation remain HUMAN DECISION actions.

Community profiles without executable plugins

Stage 10 adds vcp plugins and an opt-in declarative plugin model.

Selected bundles are local, text-only, versioned, digest-pinned, and explicitly granted capabilities. Guidance may enter bounded context; verification commands remain proposals and are never copied into AGENTS.md or executed automatically.

This does not implement a plugin runtime, remote marketplace, or native mobile profile support.

Lifecycle

The candidate adds an explicit migration:

0.9.2 → 0.9.3

which composes with the existing historical chain.

Historical release identity

v0.9.2 remains immutable:

• annotated tag object: 5693eec39f8ba24c77b5634534bff094b369880a;
• release commit: 3fba0ecc963ca896f091442bc250139c67b64ce8.

Stage 9 checks this identity but never mutates it.

Release identity

• npm: vibe-coding-production@0.9.3
• release commit: dc3c6a6
• previous immutable release: v0.9.2

Vibe Coding Production Kit v0.9.2

Vibe Coding Production Kit v0.9.2

VCP v0.9.2 is a focused follow-up to the first clean-room agent-first dogfood of v0.9.1. It keeps the successful control-plane workflow intact while fixing two places where the CLI/documentation contract could mislead an autonomous coding agent.

Highlights

Greenfield implementation context is now explicit

vcp context --include remains strict: it means the referenced repository-local file exists and its current contents should be included.

For a new implementation path that does not exist yet, use:

vcp context <task> --mode implement --planned src/new-file.mjs

--planned is repeatable and implement-mode only. It records the approved future path in the bounded context pack without inventing file contents.

This fixes the dogfood sequencing gap where the documented workflow asked the agent to build implementation context before coding while --include required the greenfield files to already exist.

Doctor strict-mode coverage is explicit

A green vcp doctor . --strict means every check currently defined by Doctor is green; it does not claim that every VCP-installed document has been customized.

Doctor now reports coverage metadata in both human-readable and JSON output:

• five core decision documents receive known starter-template marker checks;
• Definition of Ready and Definition of Done are presence-only core checks;
• USER-FLOWS.md, DOMAIN.md, and DATA-MODEL.md remain outside universal template-completeness enforcement.

This preserves project flexibility while avoiding false confidence from an implicit coverage boundary.

Agent-first workflow impact

The intended experience remains:

Developer states intent
      ↓
Agent inspects/drafts/runs VCP
      ↓
Developer resolves only genuine human-intent decisions
      ↓
Agent plans within bounded context
      ↓
Agent implements + verifies
      ↓
Developer reviews plan, evidence, and result

For implementation context specifically:

existing affected file → --include
approved future file    → --planned

Lifecycle

The package includes an explicit lifecycle migration:

0.9.1 → 0.9.2

which composes with the existing historical chain:

0.8.0 → 0.9.0 → 0.9.1 → 0.9.2

No rename or removal is required for this patch release.

Regression coverage

The v0.9.2 changes add tests for:

• greenfield planned source/test paths in implement context;
• rejecting --planned outside implement mode;
• rejecting --planned when the file already exists and should use --include;
• path traversal protection for planned paths;
• portable planned-path rendering;
• CLI --planned behavior;
• Doctor coverage metadata and human-readable coverage reporting;
• migration composition from 0.9.1, 0.9.0, and 0.8.0 to 0.9.2.

Release validation

The release source passed pre-publication validation on Windows:

• full framework validation and syntax checks passed;
• full test suite: 122 tests, 122 pass, 0 fail;
• npm package dry-run completed successfully;
• npm publish --dry-run completed successfully for vibe-coding-production@0.9.2;
• direct CLI version smoke returned 0.9.2;
• greenfield --planned smoke rendered two approved future paths before those files existed;
• lifecycle dry-run from 0.9.1 to 0.9.2 reported 6 changes and 0 conflicts;
• lifecycle apply completed with a backup, followed by an idempotent update check;
• post-update Doctor reported 13 pass, 5 expected starter-template warnings, and 0 fail, with no interrupted transaction.

Published-registry smoke is performed after npm publication; it is intentionally separate from validation of the immutable release source.

GitHub Actions on the maintainer account has historically failed before workflow steps execute, so runner infrastructure status is not treated as source-test evidence.

Vibe Coding Production Kit v0.9.1

Vibe Coding Production Kit v0.9.1

VCP v0.9.1 is a dogfood-driven patch release focused on making the framework easier to use through coding agents and on closing workflow gaps discovered while running v0.9.0 end to end.

Highlights

Agent-first usage

The intended human experience is now explicit:

Developer states intent
      ↓
Agent inspects repository + drafts VCP artifacts
      ↓
Developer answers only unresolved human-intent decisions
      ↓
Agent drives task → readiness → context → implementation → verification → review
      ↓
Developer reviews plan, trade-offs, evidence, and result

AGENTS.md, Quickstart, Start Here, CLI docs, Task Packs, Context Packs, and both READMEs now reinforce this split.

JavaScript / Node.js profile

Repositories with package.json and no TypeScript marker are now detected as JavaScript/Node.js instead of falling back to generic.

VCP reuses existing package scripts such as check, test, test:unit, test:integration, build, test:e2e, and e2e when present. It does not invent missing commands.

Readiness and verification agree

vcp ready <task> --stage implement now requires at least one executable task verification command other than INSTALL_COMMAND.

A task can no longer report implementation-ready and then immediately fail because vcp verify has no runnable plan.

Reasoned non-applicable commands stay non-executable

Values such as:

TYPECHECK_COMMAND=n/a — plain JavaScript
BUILD_COMMAND=n/a - no build step
E2E_COMMAND=not applicable — no UI

are treated as explicit engineering decisions, not shell commands. This applies both when generating new task packs and when parsing existing task verification sections.

Stronger task/source-of-truth diagnostics

Readiness now:

• rejects duplicate level-two task sections that would make parsing ambiguous;
• warns when referenced Source of Truth files still contain known starter-template signals;
• keeps reasoned n/a — <reason> statements valid where the task section allows non-applicability.

Lifecycle-safe 0.9.1 update

The package includes an explicit lifecycle migration:

0.9.0 → 0.9.1

which composes with the historical path:

0.8.0 → 0.9.0 → 0.9.1

No rename or removal is required for this patch release; the migration advances lifecycle state explicitly and safely.

Verification

Validated on Windows with Node.js 24.5.0 and npm 11.5.2:

• framework validation passed;
• syntax check passed for 24 modules;
• test suite passed: 116/116, 0 failures;
• npm run pack:check passed;
• npm publish --dry-run passed;
• package dry-run contained 88 files and reported version 0.9.1.

GitHub Actions still fails before executing workflow steps on the maintainer account, so that infrastructure failure is not treated as source-test evidence.

Release safety

• The existing v0.9.0 tag remains untouched.
• npm 0.9.0 remains immutable and is not republished.
• v0.9.1 is the patch release for these fixes.

Vibe Coding Production Kit v0.9.0

Vibe Coding Production Kit v0.9.0

VCP v0.9.0 turns the project from a copy-once engineering kit into a versioned development system with a safe lifecycle.

The key change is vcp update: initialized repositories now carry enough state to distinguish VCP template changes from project-local decisions, preview migrations, merge independent edits, stop on conflicts, recover from failed updates, and keep future releases upgradeable.

Highlights

Safe lifecycle state

vcp init now creates:

.vcp/
├── manifest.json
└── baselines/

The manifest tracks the installed VCP version, install profile, managed paths, ownership policy, baseline hashes, baseline locations, modes, and template versions.

Once initialized, VCP refuses to replace lifecycle state with init --force. Use the update engine instead.

Check, preview, then apply

vcp update . --check
vcp update . --dry-run
vcp update .

Machine-readable forms are available with --json.

When npm reports a newer VCP than the currently running CLI, VCP returns a version-pinned npx command targeting the repository that was actually checked. An older CLI never pretends it can safely apply templates/migrations from a newer release.

Explicit update plan

The planner classifies paths as:

NOOP
ADD
UPDATE
MERGE
RENAME
DELETE
ADOPT
DETACH
PRESERVE
IGNORED
CONFLICT

Any CONFLICT blocks the apply phase before project-file writes.

Managed files that disappear from a target package without an explicit migration removal become CONFLICT; packaging mistakes are not treated as permission to delete user files.

Ownership-aware behavior

VCP separates:

• managed files — safe refresh/merge when possible;
• generated adapters — local + upstream edits become conflicts;
• preserve project decisions — customized PRD/architecture/security documents are preserved;
• explicitly ignored paths — detached from VCP management without deleting local content.

Use:

vcp manage ignore AGENTS.md
vcp manage track AGENTS.md

Bounded three-way merge

For mergeable files VCP compares:

baseline
local project file
target VCP template

Independent changes can merge automatically. Overlapping changes become conflicts. The merge algorithm has a bounded work limit so large files fall back to manual resolution instead of consuming unbounded memory.

Final-newline changes are treated as real three-way changes rather than being silently normalized away.

Versioned migrations

The update engine includes an ordered migration registry for version-to-version changes. Renames and removals must be declared explicitly, and chained migrations compose across multiple historical versions.

SemVer comparison includes prerelease precedence while ignoring build metadata as required for precedence decisions.

Transactional apply and recovery

Apply follows:

lock
→ plan
→ backup
→ transaction state
→ stage
→ apply
→ rebuild baselines
→ write manifest
→ verify
→ commit state

Planning happens after acquiring the lifecycle lock, preventing a second updater from planning against stale state.

If apply fails after backup creation, VCP attempts automatic rollback.

Conservative rollback

vcp rollback .

v0.9 restores the newest safe recovery point, or the backup tied to an interrupted transaction.

Arbitrary historical partial backups are intentionally rejected because later updates may have changed additional managed paths that an older partial backup cannot reconstruct safely.

Lifecycle-aware Doctor

vcp doctor now checks:

• VCP manifest state;
• project/CLI version relationship;
• baseline integrity;
• corrupt lifecycle state;
• interrupted update transactions;
• the existing engineering-system checks for docs, commands, CI, and plan/review workflow.

Shared locking and path safety

Update, rollback, and manage mutations share the same lifecycle lock.

Managed paths and .vcp internal paths reject traversal and symlink escapes. Dead locks on the same host can be reclaimed safely; fresh foreign-host locks remain protected until the stale interval.

Existing workflow retained

v0.9 keeps the existing production workflow:

init
→ task
→ ready
→ context
→ implement
→ verify
→ independent review
→ doctor
→ release / observe

and adds the lifecycle loop:

update --check
→ update --dry-run
→ update
→ doctor

Documentation

• Quickstart
• CLI reference
• Update lifecycle
• Doctor
• English README
• Arabic README

Requirements

• Node.js 22+
• no runtime dependencies

Install from npm

v0.9.0 is published on npm:

npx vibe-coding-production init . --agent all --stack auto --yes

To deliberately execute the tagged GitHub source instead:

npx --yes github:MoeEyani/Vibe-Coding-Production-Kit#v0.9.0 init . --agent all --stack auto --yes

Toward v1.0

The next priorities are feedback-driven rather than feature-count-driven: framework/monorepo profiles, Git-aware review/release automation, domain security profiles, prompt evaluation, architecture fitness functions, and an extensible profile/plugin model.

The v0.9 goal is narrower: make the current system safe to adopt and safe to evolve before asking users to depend on it.