{"_id":"@angryss/vep","name":"@angryss/vep","dist-tags":{"latest":"2.0.0"},"versions":{"2.0.0":{"name":"@angryss/vep","version":"2.0.0","description":"VEP 2.0 canonical process bundle and reference model","type":"module","bin":{"visu":"bin/visu.js"},"scripts":{"build":"npx --yes --package typescript@7.0.2 tsc --noEmit false --outDir dist -p tsconfig.json","test:cli":"node tests/conformance/oracles/governed-test-command.mjs cli","test:conformance":"node --test \"tests/conformance/**/*.test.mjs\"","test:determinism":"node tests/conformance/oracles/governed-test-command.mjs determinism","test:integration":"node tests/conformance/oracles/governed-test-command.mjs integration","test:legacy-isolation":"node tests/conformance/oracles/governed-test-command.mjs legacy-isolation","test:unit":"node --test \"tests/unit/**/*.test.mjs\"","typecheck":"npx --yes --package typescript@7.0.2 tsc --noEmit -p tsconfig.json"},"engines":{"node":">=24 <25"},"license":"UNLICENSED","_id":"@angryss/vep@2.0.0","_integrity":"sha512-2xv9kqH5Aa42xf0l4AYnXS8ljxdUGCaoIp05PIFoL576i/w6sxIWmJqMclfy8a87Z1XQc2rasDirnkuOxOTp8g==","_resolved":"D:\\Workspaces\\personal\\hermes-engine\\vep-2-stable-release-readiness-angryss-evidence\\artifacts\\canonical-a\\angryss-vep-2.0.0.tgz","_from":"file:D:/Workspaces/personal/hermes-engine/vep-2-stable-release-readiness-angryss-evidence/artifacts/canonical-a/angryss-vep-2.0.0.tgz","_nodeVersion":"24.18.0","_npmVersion":"11.16.0","dist":{"integrity":"sha512-2xv9kqH5Aa42xf0l4AYnXS8ljxdUGCaoIp05PIFoL576i/w6sxIWmJqMclfy8a87Z1XQc2rasDirnkuOxOTp8g==","shasum":"e0518fa1a0146800d0f09f36480e4eab2da0b28e","tarball":"https://registry.npmjs.org/@angryss/vep/-/vep-2.0.0.tgz","fileCount":32,"unpackedSize":243646,"signatures":[{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEUCIQC5flk9lBD86hzxVSu3zgvzpgDPBHkXL6FRalUepG3YcgIgY2V+Ffq3PGWbv9rGoPqknJPkv/y/GON6NHSKVvB8m5Y="}]},"_npmUser":{"name":"csharpwiard79","email":"csharpwizard79@gmail.com"},"directories":{},"maintainers":[{"name":"csharpwiard79","email":"csharpwizard79@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages-npm-production","tmp":"tmp/vep_2.0.0_1787257245966_0.4535889902856731"},"_hasShrinkwrap":false}},"time":{"created":"2026-08-20T20:20:45.751Z","2.0.0":"2026-08-20T20:20:46.108Z","modified":"2026-08-20T20:20:46.421Z"},"maintainers":[{"name":"csharpwiard79","email":"csharpwizard79@gmail.com"}],"description":"VEP 2.0 canonical process bundle and reference model","license":"UNLICENSED","readme":"# VEP 2.0\n\nVEP 2.0 is a contract-first engineering process for bounded, testable change. This package contains the stable canonical process specification, schemas, artifact templates, reference implementation, CI reference, and calibrated fixtures.\n\n## Installation and versioning\n\nInstall and pin the stable release exactly:\n\n```text\nnpm install --save-exact @angryss/vep@2.0.0\n```\n\nFoundation, Workspace Foundry, Darkhorse, and other consumers must use the exact `2.0.0` dependency identity when their separately authorized integration begins. A floating range is not required. Moving from `2.0.0` to a future patch or minor release is a separate governed consumer change: the consumer selects and verifies the new exact package version, but does not copy or mirror VEP's internal Contract, proof, review, or publication authority.\n\n## Developer workflow\n\nThe developer-facing lifecycle has five stages:\n\n1. **Discover** — identify the intended outcome, repositories and paths in scope, exclusions, dependencies, and risk triggers. The lifecycle command is `visu discover`.\n2. **Plan** — prepare and approve the Contract/Plan before implementation. It records intent, scope, owner, risk tier, assumptions, dependencies, acceptance criteria, proof strategy, governed authority, rollback, and the path to done. Run mechanical preflight before mutation to prove that repositories, paths, dependencies, governed expected-result records, state, and publication prerequisites are available. The lifecycle command is `visu plan`.\n3. **Implement** — make only the bounded changes authorized by the Contract/Plan. Implementation does not create new expected truth or silently broaden scope.\n4. **Test** — run `visu test` against independently defined expectations, then `visu review`. Proof is deterministic where material and binds the exact Contract, candidate, and result. There is one independent review stage. `CHANGES_REQUIRED` returns to a bounded implementation correction, reruns the relevant proofs, and returns to that same review stage; it is not approval and does not start another lifecycle.\n5. **Close** — when publication applies, publish at most once and verify the external result. Run `visu close` only after proof and review pass, publication is verified or explicitly inapplicable, handoff and next action are clear, and known technical and process debt are both zero.\n\nThe installed package exposes one public entrypoint, the `visu` executable, with exactly these five concise lifecycle commands: `visu discover`, `visu plan`, `visu test`, `visu review`, and `visu close`. Run `visu discover --json` to verify the installed developer entry. Commands that evaluate a workflow artifact accept `--input <file.json>` and return a real structured outcome, next action, and fail-closed exit status. The normal durable artifacts are `contract.yaml`, `proof.json`, `review.json`, and `publication-closure.json`; internal authority machinery is not required knowledge for normal use.\n\n## Risk tiers\n\n- **Tier 1** is normal lightweight work in one repository and does not inherit advanced controls. Behavior-affecting features and fixes use human independent review. Mechanical independent review is limited to Contract-qualified canonical generation, formatting, metadata, or nonsemantic documentation with closed output scope, independent verifier implementation/configuration, and no semantic or public-contract change.\n- **Tier 2** adds human independent review and the necessary contract or architecture rigor when work crosses repositories or affects a public contract, dependency, architecture, persistence, or data ownership.\n- **Tier 3** adds advanced controls only for genuinely high-risk work involving security or privacy, release authority, destructive or irreversible action, regulated data, high blast radius, or nontrivial rollback. Architecture review is required, but the same five-stage lifecycle remains in force.\n\nThe highest applicable trigger wins. Risk may be escalated explicitly, but it is never silently downgraded.\n\n## Proof, review, and correction\n\nExpected results, implementation-author identities, and reviewer eligibility are loaded internally from the approved canonical Contract; requests cannot supply authority resolvers, expected facts, authority documents, or reviewer-independence flags. Every authority decision binds the Contract/change, implementation candidate, Proof Result, proof when applicable, repository, lineage, process/schema versions, and authority sequence. Required failures are nonzero, nonmutating, fail closed, and provide one explicit recovery action. Review is independent of implementation and is bound to the exact Contract, candidate, and Proof Result. A review decision is `APPROVED` or `CHANGES_REQUIRED`; no review-of-review or proof-of-proof is introduced.\n\n## CI reference and release verification\n\n[`ci/vep-check.yml`](ci/vep-check.yml) is the reference GitHub Actions job. It invokes the governed npm command surface rather than redefining process semantics: clean install, unit, conformance, integration, CLI, determinism, legacy-isolation, typecheck, build, and package dry-run. Conformance includes strict schema/artifact validation and exact P10 progression/package verification.\n\nRun the stable release checks locally from this directory:\n\n```text\nnpm ci\nnpm run test:unit\nnpm run test:conformance\nnpm run test:integration\nnpm run test:cli\nnpm run test:determinism\nnpm run test:legacy-isolation\nnpm run typecheck\nnpm run build\nnpm pack --dry-run\n```\n\nThe four `fixtures/` trees contain Tier 1, Tier 2, Tier 3, and negative developer-experience inputs. They calibrate existing process semantics; they do not define expected results or create new authority.\n\n## VEP and optional authoring tools\n\nThe VEP Contract/Plan is the canonical process authority. Darkhorse or OpenSpec may provide an optional authoring or tooling representation, but neither is a competing plan authority and neither is required to use VEP 2.0. The stable package does not itself integrate Darkhorse, OpenSpec, Foundation, Workspace Foundry, or any consumer; each integration requires a separate authorized Contract after stable publication and independent verification.\n\n## Stable support and recovery boundary\n\nPublished `2.0.0` is immutable. A failure before registry visibility permits no assumption of success: observe the registry again and resume only under fresh transaction-scoped authority. If publication becomes visible but independent verification fails, stop adoption and investigate against the prepared tarball; do not overwrite, force-replace, or rebuild `2.0.0` as a substitute. A required correction is delivered as a separately governed successor patch, normally `2.0.1`, with its own proofs, review, publication operands, and verification. A wrong target or ref mutation is handled at that target without rewriting the valid `2.0.0` package history. Downstream incompatibility likewise pauses adoption and uses a governed patch or consumer-side rollback to the last verified exact dependency.\n\n## Closure standard\n\nClose only with verified proof and review, verified or inapplicable publication, a usable handoff, an understandable next action, and zero known unaccepted technical or process debt. If any required fact is missing, ambiguous, stale, or inconsistent, stop fail-closed and follow the reported correction action.\n","readmeFilename":"README.md","_rev":"1-5cbcb9e641840dca069d527869344a5a"}