What's New

Latest changes to the VisiTrans Claude Toolkit.

On version numbers. Up to v5.0.1 the toolkit shipped under a single version. Since the SPEC-163 plugin split each plugin versions independently — vt-base, vt-product-dev, vt-office, vt-toolkit, vt-pm-intake, vt-brand, vms and finance — so releases below that point are dated and name the plugins that moved. plugins/registry.json is the authority.

vt-toolkit 1.2.0 (2026-09-18)

Session restore answers an account switch with a report, not terminal windows (SPEC-203, PR 1 of 2). Claude Code keeps transcripts per folder; the desktop app keeps its sidebar per account. After an account switch the sidebar is empty while every conversation is still on disk — and vt-t-session-restore could only open terminal windows. Measured across 20 repositories and 132 conversations: five of the six windows it opened resumed desktop conversations, two desktop sessions were missed, one was opened twice, and in one repository the running terminal session was an old passive CLI conversation while the real work sat in two desktop conversations that the output did not distinguish. claude-boot now reads the desktop store next to the folder store and prints what is missing per repository, dated by conversation rather than by file mtime — the mtime route dated five repositories to the same shutdown minute, the failure references/mechanics.md already warned about — with the open questions from each transcript's tail and a shell line to paste. No window opens for a desktop session. Occupancy is decided per working directory, resume is guarded and verified like open (they had built different duplicate-start slugs, so two commands could put two processes on one transcript), and a start that produces no process is now reported as a failure in the same run instead of as a started window.

Two security findings closed on the way: the report no longer executes a scanned repository's own git config, and the emitted shell line quotes the conversation id and the slug as well as the path. The adopt command (waves W8–W10) ships separately as PR 2.

vt-base 6.2.6 · vt-product-dev 1.2.3 (2026-09-05)

The version gate now checks the same five mirrors the suite does (BUG-211). A plugin's version is written in five files — plugin.json, plugins/registry.json, the marketplace.json entry, its metadata.version for vt-base, and the | Version | row in docs/plugins/<name>.md. The finalize gate compared the first two; guard 22 compared all five; and the finalize skill's Step 2d told the agent to hand-edit the first two. Four bumps in a row followed those instructions, passed the gate and failed the suite on CI — SPEC-169, SPEC-170, BUG-031 (repaired two days later) and BUG-207 (merged red, repaired the same day). Guard 22's own comment had recorded the first two misses and fixed the detector; nobody had fixed the producer, which is the N-copies/N−1-checks shape count-reconciliation-single-source.md describes. The list now lives once, in plugins/vt-base/lib/version_mirrors.py: the gate reads it and fails closed if the library is missing beside it, guard 22 reads it, and Step 2d runs version_mirrors.py set, which writes every mirror by targeted edit and proves by re-parsing that exactly one field changed per file. Guard 95 is the coupling proof — reverting any single mirror makes the gate fail and name it. This release was bumped with the new command and passed the gate it changed: the first bump on record that needed no follow-up commit. Found on the way: guard 22's template-invariant block had lost an import, and its crash went to stderr inside a { } | paste group while the assertion printed ok. A crash is not a pass; both python runs now feed the assertion and two crash injections fail it.

A fork's agent: is a tool boundary, not an identity (BUG-207, vt-product-dev 1.2.2). BUG-046 had been fixed by giving the review skill an agent: line, on the recorded rationale that naming the agent gives a forked skill a routable identity so sub-agent replies can reach it. BUG-207 filed the other five forks on that premise, and the fix was built as filed — two more bindings, a widened orchestrator, a class guard — then verified live before commit with throwaway fork skills in nested sessions, reading the forks' own subagent transcripts. The premise did not hold: a worker messaging a bound fork by its agent name fails with the same "No agent named '' is reachable" as the unbound control fails with general-purpose, while replies through the Agent tool's own result arrive either way. What agent: does do is make the agent's tools: list the fork's permission boundary — the bound probe had exactly Agent and Read and could not invoke a skill — so the drafted bindings would have removed Edit, Write and Skill from the finalize skill. They were reverted. Guard 94 now asserts, for every fork that is bound, that its agent lists every tool the skill's body names, with a seeded control that an unbound dispatching fork is not flagged; the two comments that carried the false rationale say the measured mechanism instead. Severity went from high to medium, and its version bump became the fourth two-of-five miss above.

vt-base 6.2.5 (2026-09-02)

React render defects had no reviewer. The review pipeline had reviewers for Angular, NestJS, PHP, Python and TypeScript, and not one of them looked at JSX render semantics. SPEC-113 routes a framework reviewer instead of the generic TypeScript one when a root manifest is found, so a React project fell through to kieran-typescript-reviewer — which said nothing about keys, reconciliation or rendering; grepping it for those words returned one unrelated line. The cost was paid in a product repository: two direct siblings carried the same key={tc.id}, React treats duplicate keys among siblings as unsupported and appended another copy of the first block on every re-render, and because the view polls every 25 s and on window focus, a tester watched a row of buttons grow to eleven after ten polls. The type checker, the linter and 1020 passing tests were green the whole time, and so was the review. Section 10 of kieran-typescript-reviewer now checks sibling key uniqueness and keys as identity rather than index.

The lesson worth keeping is not about React. Two of the three checks are about what counts as proof. "It works in the built app" cannot clear a duplicate-key defect, because that warning exists only in the development build. "The tests pass" cannot clear a re-render defect when the harness runs environment: 'node' and renders once — measured, not assumed: renderToStaticMarkup emits no duplicate-key warning and renders both children happily. A green suite is evidence for what the harness can observe, and a reviewer has to ask which of the two it is looking at.

Guards, CI and a bug-ID allocator (2026-08-20 — no version bump)

Bug IDs get an allocator, by reusing the spec one rather than cloning it (BUG-047). Bug IDs were hand-assigned by a max + 1 shell scan, and two sessions scanning the same main compute the same answer: on 2026-08-10 six distinct defects were filed under BUG-041/042/043, and on 2026-08-19 BUG-085/086 were claimed twice for unrelated bugs hours apart. Scanning harder cannot fix that — the fix has to reserve. allocate_spec_id.py therefore gained --kind {spec,bug} instead of a second allocator being written: that file is 1139 lines of concurrency work whose every lesson applies verbatim to bugs, and only constants, two regexes, the directories and the output label differ. Verified at 12 concurrent claimants → 12 unique IDs; with the claim marker suppressed, 1 distinct ID out of 12. That negative control is the load-bearing measurement, because "12 unique from 12 runs" is otherwise satisfied by sequential-enough execution with no synchronisation at all. triage-bugs no longer computes IDs — it calls the allocator and uses stdout verbatim.

Guard filenames get the same uniqueness check (BUG-094). The identical collision existed for guard filenames and was worse: two bug reports both writing BUG-0NN.md make git conflict, whereas two guards with different names sharing a numeric prefix merge cleanly. run-all.sh globs [0-9]*.sh, so both run — no error, no lost coverage, and every later reference to "guard NN" ambiguous. It had happened five times; four pairs (04, 19, 24, 25) were never noticed. Guard 63 plus a shrink-only baseline banking the four historical pairs closes it, and the ratchet runs both ways: a banked prefix that is no longer duplicated fails, so a fixed pair cannot regress under its own excuse. The first version of that baseline enforced "never grow this" with nothing but those words, and appending one line silenced the guard entirely — documentation asserting a rule is not the rule, so the ceiling now lives in the guard rather than in the file it governs.

Hook-layer verifiability — guards for controls that cannot fire (SPEC-183). A registered hook that cannot read its input is indistinguishable, from every report anyone looks at, from a hook that ran and found nothing. partition-guard.sh "never warned once" by its own header; secret-scanner.sh shipped the same way; and Check 0 of repo-audit-ci.sh was never broken at all — it was never called, so nine trusted-hook pins drifted for up to 144 days behind a verifier working perfectly in a script nothing invoked. Six guards (63–68) now make each of those impossible, and each prints its assertion count so it cannot quietly check nothing. The generalisable lesson: a denominator you cannot see is not a denominator — every defect here has the same shape, a check reporting success over an empty set, so the guards assert how many things were examined and go red when that count falls. Amnesty is designed out rather than discouraged: both ratchets fail in both directions, so leaving a banked entry in place after its defect is fixed is itself a failure. CI now exists and runs on macOS with zero exclusions; the Linux gap was filed as BUG-095 rather than hidden.

vt-base 6.2.4 · vms 2.2.1 (2026-08-19)

The vault guard could be escaped two ways nobody had filed (BUG-093, vms 2.2.1). What was filed was an exit-code defect — exit 1 where the PreToolUse contract requires exit 2 plus a permissionDecision payload — plus a claim that the guard was registered in no hooks.json. The exit code was real; the registration claim was misleading, because registration is the union of hooks.json, agent frontmatter and shipped settings.json, and the filing checked only the first. What nobody had filed was worse, and both allowed writes outside the vault: a sibling-prefix escape (vault matching vault-evil/), because a string-prefix test stood in for a path-boundary test; and a ../ traversal, because realpath -m is unsupported by macOS /bin/realpath, so normalisation had never run on this platform and the || printf '%s' fallback silently kept the raw path. A silent fallback to an unnormalised value inside a containment check converts a normalisation failure into a bypass. It now fails closed. The guard runs the hook rather than grepping it — the exit-code defect survived review precisely because the file's own header comment read correctly.

The hook audit stops over-claiming (BUG-090 + BUG-091, vt-base 6.2.4). BUG-077 had given the audit a verdict reading N/N approved-location hooks pinned, and two things made that sentence false: configs/user-global/hooks/ — which holds the only hook the shipped settings.json registers — was in no scanned location, and approved_locations was read by no script at all, so a pin naming a path in no approved location was still counted (28/28 when only 27 were). BUG-077 had fixed closure in one direction — "is every file in an approved location pinned?" — and nothing asked the converse. The scan's base list stays deliberately hardcoded rather than read from the manifest, so that whoever edits that file cannot delete a directory from its own scan.

A failed backup reported success, and --safe merged anyway (BUG-086, scripts/setup.sh). do_backup_now() checked whether rsync existed and never whether it succeeded, and a shell function returns its last command's status — here an echo — so a failed rsync produced ✓ Backup created, a Restore: line naming an empty directory, and a return of 0. The generalisable part is why set -euo pipefail did not help: every caller invokes the function inside || { … } or if ! …, and errexit is suppressed throughout a function called in that position. The call site's own error handling is what disables the safety net inside the function. The data-loss path was the printed restore instruction — rm -rf ~/.claude && mv $backup_dir ~/.claude — inviting the user to delete a working config and replace it with an empty directory; failure now removes the partial directory so it cannot be mistaken for a backup.

vt-base 6.2.3 (2026-08-17)

The hook-integrity verifier could not fail open (BUG-077). repo-audit-ci.sh's hook-integrity check ran BELOW the .repo-manifest.yaml early exit, and the toolkit repo has no manifest — so in this repo the check never ran at all, while printing PASS (all checksums verified) on every run. Nine pins had drifted, the oldest by 144 days. Moving it above the gate was necessary and insufficient: review found five further ways to bless a backdoored hook, and the last three were introduced by the fixes for the first two. The actual root cause was that declared and checked were both derived from the same parsed manifest, so the check could only prove self-consistency. A checksum allow-list is only an allow-list if it is closed — every executable in an approved location must be pinned — and the filesystem supplies the independent side of that comparison. The pattern is written up as verdict-needs-a-denominator.md (P-005); this defect had been independently rediscovered six times in this repo, twice inside the work that fixed it.

vt-base 6.2.2 · vt-product-dev 1.2.1 (2026-08-13)

The deliverable-type vocabulary is now closed (BUG-031). persona-select.sh matched deliverable types by exact string identity, so a spec declaring docs — or doc, documents, documentation, or any mixed case — did not match the single spelling document and silently lost document-quality-reviewer. Worse than a missing reviewer: an unrecognized token produced no warning and exit 0, so the review ran at the constitutional floor and reported success, and a spec author had no way to tell "reviewed thoroughly" from "reviewed by nobody". Two shipped specs proved it — SPEC-141 declared [skill, script, reference] and SPEC-140 declared [script, skill], and not one of those five tokens was ever legal. The vocabulary is now closed at 12 legal types, aliases canonicalize, and an illegal token exits non-zero naming the offender. Two findings reproduced the bug inside its own fix, which is the part worth remembering: --types "," returned output byte-identical to the unfixed selector because the whitespace guard ran before tr turned commas into whitespace, and for t in $norm_types did pathname expansion, so --types '*' selected reviewers based on what files happened to sit in the working directory.

partition-guard.sh misread every manifest (BUG-041). An awk helper carried two defects, byte-identical since 2026-02-13 — latent, never a regression. The key was passed as an unanchored regex, so it matched the paths: line under every partition; and the reset rule /^[[:space:]]*[^-]/ matched the list-item lines themselves, because [[:space:]]* can match zero characters and [^-] was therefore tested against the leading space. With no next on the print rule, every list truncated to its first item. The two defects partially cancel, which is why the filed report was wrong about the mechanism — and why its own repro missed it, using a fixture with one path per partition, the single shape in which "first of each" and "all of each" are indistinguishable. Real damage: 6 of 12 declared roots misclassified. The three manifest readers are now held to one contract by a test that extracts and runs each reader from its own file, because an earlier revision hand-copied the audit's awk into the test, which meant breaking the real audit left the test green.

The count-drift detection signal is derived per plugin, and now executed (BUG-067). critical-patterns.md P-003 published grep -c "^vt-c-" skill-symlinks.manifest as the detection signal for components.* drift. It returns 0 for seven of eight plugins, and 0 reads exactly like "no drift". The filed premise — that SPEC-163's split caused it — was wrong and was corrected rather than built on: measured at the authoring commit, the signal was already wrong for finance and vms on day one. That distinction decided the fix, because a doc that rotted argues for better rename sweeps whereas one born plugin-blind argues for deriving the prefix and making something execute the published command. Fixing prose without pinning it only resets the same clock, so a guard now runs the derivation the doc publishes.

The toolkit stops shipping one maintainer's beads hook (SPEC-177). configs/user-global/settings.json shipped command -v bd >/dev/null 2>&1 && bd prime || true on both SessionStart and PreCompact, so every user's session ran one maintainer's tool unasked — and SECURITY-CONFIG.md's own rule ("any hook not in this list should be investigated") had been amended to approve it, which is how a personal default becomes policy. It is an unqualified, PATH-resolved binary with its output and exit code swallowed by || true, and bd is a two-character name that collides with a real shell utility, so the shadow needs no malicious intent. Both entries are gone. One entry deliberately survives and that is the harder half: the update reminder stays in the shipped settings.json, because a hook whose job is to report "the plugin did not load" cannot live inside the plugin. The obvious migration advice — "run setup.sh --safe" — was not published, because probing a real machine showed --safe only rewrites a key carrying the _managed_by marker and a real ~/.claude/settings.json was measured unmarked, making that advice appear to work while silently doing nothing.

vt-base 6.2.1 · vt-product-dev 1.2.0 (2026-08-12)

Parallel-work guardrails and an opt-in spec/phase statusline (SPEC-167). V025 had every piece for parallel work — vt-c-git-worktree, activate waves, context: fork review/finalize, domain-dashboard — but no honest account of what running several worktrees costs, and no spec/phase progress surface at all. The multi-worktree pattern doc now carries a Parallel-work hazards and guardrails section, and all four hazards in it are ones this repo has already paid for. The new vt-d-statusline-spec-phase renders the active SPEC-NNN, its workflow phase, context usage and session cost on one line — and the toolkit ships the script only, deliberately adding no statusLine key, both because a statusline is personal preference and because merge_settings.py is user-wins, so a shipped key would silently never reach anyone who already had their own. The statusline treats .active-spec as untrusted project content: before the byte-bound and character allowlist, a committed .active-spec could inject an OSC-52 sequence that silently rewrote the reader's clipboard on every render, stall the render path for ~8 s with a 200 KB single line, or escape the project root via ../. A planned multi-task view was dropped at a feasibility gate — Claude Code exposes no cross-session registry.

vt-base 6.2.0 (2026-08-11)

The output-clarity standard and its gate (SPEC-170). One documented standard (answer-first, plus a mandatory "Next actions" block), one mechanical gate (bin/check-output-contract.sh), a 190-assertion suite, and conformance for the 9 core phase skills. A skill declares its class with output_contract:, and the field is opt-out — an absent value means multi-step and the block is required. It is a shrink-only ratchet rather than a flag day because the strict rule measured 12 of 137 skills already conforming, and hard-failing the other 125 is the "mass false-fails → gate gets disabled" outcome the mechanism exists to avoid. BASELINE_MAX is an exact-equality assertion, not <=, so the suite goes red on progress too and every conformance is banked deliberately.

The review found six High defects, four of them in the gate's own correctness, and three were visible only because seven independent reviewers read the same diff. The anchor matched inside fenced code blocks, so a skill was certified as conforming by a quoted example — and the suite's "all 9 core skills PASS" assertion was green because of that false positive. A case desync (detection used grep -i, the label-stripper was case-sensitive) reopened the placeholder hole one iteration after it had been closed. The standard itself documented a label the gate rejects, so an author following the single-source statement verbatim got a hard FAIL telling them to add the block they had just added. And the nine-core-skill assertion evaluated nothing on any path containing a space, dying with exit 2 while printing ✓.

Shipped alongside, at the repository root rather than in the plugin: scripts/run-tests.sh no longer executes files git has never seen, and gates everything pytest auto-loads — conftest.py, pytest.ini, pyproject.toml, tox.ini, setup.cfg — because addopts = -p <module> imports arbitrary code at pytest startup. A phase-5 security scan run after the review gate had been graded PASS found four more, each reproduced end to end: a glob metacharacter in a filename defeated the gate in every group, because paths reached git as unprefixed pathspecs that git glob-matches; the pytest content check stopped at the test directory while pythonpath imported modules from outside it; RUN_TESTS_ROOT disabled the whole gate silently on a trailing slash; and a newline in a filename failed open. Every pathspec now carries :(literal).

vt-base 6.1.0 (2026-08-09)

PHP stops being reviewed as TypeScript (SPEC-168 Wave 1). persona-select.sh knew angular.json, nest-cli.json and the Python markers and nothing else, so a PHP repo fell through to kieran-typescript-reviewer — and a pure-.php diff was worse than that, selecting no language reviewer at all. Four repos were affected. The defect that mattered was found by execution, not by reading: the plan's own first-draft idiom, [ -f "$PROJECT_ROOT"/*/composer.json ], was run against a repo carrying four depth-1 composer.json files, the glob expanded to four operands, [ exited 2, and the branch was skipped silently — the same silent-drop class, reproduced before a line of implementation existed. Depth 1 is the point rather than a generalisation: one affected repo's real composer.json sits at visifair-files/composer.json, so a root-only marker check — the obvious implementation, and the one every sibling detector uses — would have shipped green while missing the single repo the reviewer was written to unblock. The spec's scope was narrowed at the gate on a measurement: of 73 repos, 8 carry a .repo-manifest.yaml and 0 of the 4 PHP repos do.

vt-toolkit 1.1.0 · vt-product-dev 1.1.0 (2026-08-08)

The skill scaffold writes a real "Next actions" section, and tells authors to verify it with check-output-contract.sh. A scaffolded-but-unfilled skill FAILS the gate by design — [TODO] placeholders do not count as content — so the scaffold cannot be mistaken for a finished skill. init_skill.py no longer accepts an unvalidated skill name: it was interpolated into both the YAML frontmatter and the output directory path, so a newline injected frontmatter keys and ../ escaped the target tree, where mkdir(parents=True) would create it and drop a 0755 script. Names are validated, the write path is confinement-asserted, and all template writes are explicitly UTF-8.

vt-product-dev 1.1.0 also publishes three changes made on main without a version bump — the php-reviewer routing, a routable identity for the review fork (a context: fork skill with no agent: defaults to the built-in type general-purpose, which is a type name and not an address, so sub-reviewer replies failed and lost five reports in one review pass), and a Beads step that guards on the database rather than its tracked export. That list is explicitly not the complete set: an independent audit found main had changed 11 files under this plugin since 1.0.1, spanning at least seven distinct changes.

vt-base 6.0.0 — BREAKING · vt-toolkit 1.0.1 (2026-08-07)

The installer stops destroying user config (SPEC-169 Wave 1). Three defects destroyed user data at exit 0, with no warning and nothing counted. The directory-ownership hash read only regular files and threw away filenames, so a user directory holding only symlinks produced the SHA-1 of empty input — indistinguishable from an empty directory, and adopted as toolkit-owned and rm -rf'd. MAJOR because FR-8 deletes --overwrite and its --full alias: README.md told every user to run --full until this release and it now exits 1, and while the migration is one word, a documented CLI flag disappearing is breaking.

The durable lesson is that a green suite is not evidence. The setup suite was 23/23 while two of those three defects were live, and 29/29 while the third was, for a reason worth stating: the acceptance fixture seeds a regular SKILL.md into its decoy directory, and a regular file is exactly the input shape for which the broken hash happened to work. Two assertions written for the fix were themselves vacuous and only mutation testing caught it. Review structure mattered more than review effort — five consecutive passes wrote their gate at zero reviewer returns, and in every one the late arrivals carried the most severe finding, including the CRITICAL that wrote outside ~/.claude. A pass with no returns is INCOMPLETE, never a result.

vt-product-dev 1.0.1 (2026-08-05)

The finalize version gate had been dead since 5.0.0 (BUG-037). workflow-5-finalize/SKILL.md told the agent to run $CLAUDE_PLUGIN_ROOT/scripts/check-finalize-versions.sh with a documented fallback of ../../scripts/…; the skill lives in vt-product-dev, so both resolved to a directory that does not exist, because the script is in vt-base and SPEC-163 W5 had moved the skill out from under it. It survived so long because the skill documented a graceful-degradation branch — "if the script fails to run (command not found, Python3 missing, etc.) … display warning but proceed" — and that message cannot distinguish "your machine is missing a dependency" from "this skill points at a path that has not existed for months", so a toolkit defect rendered as an environment quirk. Dogfooding confirmed it twice, each run reporting Version gate: SKIPPED and attributing it to permissions. Nothing in the suite executed a skill's instructions, so a path written in prose had no coverage at all; the new guard resolves every script path a SKILL.md tells the agent to run, and immediately found a second instance in activate/SKILL.md that the manual sweep had missed. Measuring the guard's own blind spot re-scoped BUG-019 too: 21 non-resolving invocations across six vt-office skills.

v5.0.1 (2026-08-04)

The marketplace half of the plugin registration never existed (BUG-030 / BUG-032). .claude-plugin/marketplace.json declared the marketplace as company-saas-toolkit — an unreplaced scaffold name — while settings.json shipped the enable flag vt-base@visitrans. For roughly six months claude plugin list reported enabled: true for an id that claude plugin details answered with "Marketplace visitrans not found". Nothing caught it because plugin identity is mirrored across five surfaces with no test pinning any of them together, and the omitted mirror was the highest-coupling one. The fix for BUG-032 was itself a silent regression, and that is the durable lesson: deleting the schema-invalid workflows key satisfied the validator, but generate-skill-map.sh was its only reader, so the next regeneration would have rendered four documented pipelines as empty. The review had to be run twice and the second run inverted the first — six reviewer subagents were dispatched, none returned before the gate was written, and a fact recorded under verified-good turned out to be true but inverted in significance once they did. Records were also asserting things that were not true: three follow-up bugs listed as "already filed" did not exist, so four findings recorded as deferred to tracked work were tracked nowhere.

v5.0.0 — BREAKING (2026-08-02)

The split lands: core-standards becomes vt-base (SPEC-163 W5–W8). 132 skills, 36 commands and 62 agents partitioned across eight plugins, each with its own prefix — vt-c- base, vt-d- product-dev, vt-o- office, vt-t- toolkit, vt-p- pm-intake, vt-b- brand, vt-v- vms, vt-f- finance — with no aliases and no deprecation window, because Claude Code keys skill identity on the SKILL.md name: field, so a second symlink cannot alias a skill. The rename had to be one commit: resolve_plugins() hard-fails on a dependency directory that does not exist, so a plugin still naming core-standards after the rename aborts the whole install rather than just its own. Old names stop working on upgrade; every rename is listed in the migration guide.

The review pass found four defect classes the suite could not see. The skill and command halves verified exactly — 132 and 36, zero lost, duplicated or colliding. Everything else was the agent layer and the tests. Agent identity turned out to be a fifth reference class the spec's own taxonomy did not cover, since that taxonomy is entirely about skill references. The pruner could not reach agents at all: it globbed one level deep while every agent link lives in agents/<category>/, so the agents branch never inspected a single link. Four tests were structurally inert — they could not fail for any input, one looping over a glob from which the relevant skills had already been moved. And counts stopped being literals: macros.py had been narrowed to vt-base's own 15 / 43 / 7 while every consumer rendered them as toolkit-wide, so a getting-started page opened with "The toolkit ships 15 skills" against a real 132. The macros now derive from the per-plugin manifests at build time.

v4.0.1 (2026-07-29)

Product scoping matched nothing (SPEC-163 Amendment A3). The amendment was drafted as "drop W4, FR-8 is already satisfied", and checked against disk, two of its three premises were false. The defect neither the plan nor the amendment saw: every glob in projects.yaml's products: block encoded the repository parent-directory numbering from before the renumber, so each product's paths: block pointed at a directory that no longer existed. The globs are corrected and every generated block regenerated. W4 is still dropped, but on inverted reasoning — its remaining action would have stopped the three skills deploying at all.

v4.0.0 — BREAKING (2026-07-29)

The core-standards split, foundation (SPEC-163 W0–W3). The non-destructive half: deployment enablement, five registered-but-empty plugin scaffolds, the retirement of nine deprecated skills, and the mechanical reference-rewrite tool. No skill was renamed or moved here. MAJOR because W3 deletes nine skills that deployed as working commands — all nine had carried a [DEPRECATED]/[SUPERSEDED] marker naming their replacement through several MINOR releases, which makes the removal permissible but does not make it non-breaking.

Three amendments all came from premises that failed on contact with disk, the first being the one that shaped the whole release: a W0 runtime spike returned FAIL on aliasing, because Claude Code keys skill identity on the name: field, and the fallback — one real redirect directory per alias — was priced at 113 → 133 visible skills. The reference-rewrite tool is the load-bearing piece once aliases are withdrawn, and its first implementation measured 8m47s for seven names, extrapolating to hours. The assignment itself was made executable rather than left as prose in an evaluation appendix, which had already drifted twice.

v3.53.0 (2026-07-28)

Concurrency-safe SPEC-NNN allocation (SPEC-165) — spec IDs were computed by a hand scan of the current worktree, so two branches in flight allocated the same number, and a stale long-lived branch mis-numbered every spec created on it. Both are documented incidents in this repo. A new stdlib-only allocator (allocate_spec_id.py) replaces the hand scan in both spec-from-requirements and specs-from-prd: the ID is 1 + max(working tree, every local and remote ref, a stored counter), read and written back inside one fcntl.flock critical section, against a store at <git-common-dir>/vt-spec-counter — the one path identical from every worktree of a clone. The load-bearing detail is git rev-parse --path-format=absolute --git-common-dir: without --path-format=absolute git may return a relative path that resolves to the linked worktree's own .git, which silently is the bug, with no visible symptom.

The contract is that a numbering problem must never block spec creation, so every failure — no git, unwritable .git, lock timeout, git older than 2.31 — degrades to a local scan with a named warning: on stderr and still exits 0. What makes that safe under concurrency is that the real arbiter is not the counter but an O_EXCL claim marker written on every allocation, locked and degraded alike: O_EXCL creation is the only primitive atomic across both paths, and the two paths run simultaneously by construction, since the sole cause of a lock timeout is another claimant holding the lock right then. The counter is a fast floor hint. A 96-assertion suite pins it, including a --no-lock negative control that must produce duplicates (without it the race test passes with no locking at all, by accidental serialization) and region-scoped structural assertions where each positive is paired with a mutation that must make the identical check fail.

Two durable lessons, both recurrences of existing patterns. A security fix expressed only as prose in a SKILL.md is unenforced: the shell-quoting rule for the attacker-settable specs_directory field is now pinned by assertions with must-fire mutations, not just stated. And a plausibility bound applied to one input must be applied to the inputs it is compared against — bounding the counter against the scanners while leaving the scanners unbounded let one repo-tracked SPEC-<20 digits> poison every later allocation in the clone.

v3.52.0 (2026-07-24)

Proactive Open Brain Capture (SPEC-161) — a new opt-in, dormant-by-default skill (vt-c-openbrain-capture, 127 → 128 skills) captures the core facts of a session — external-stakeholder facts, decisions and their rationale, durable domain/process knowledge — to Open Brain via capture_thought, sanitized and deduplicated. It is the always-on judgment layer above SPEC-089's fixed-point capture; both write the same store so dedup sees everything. A project opts in by dropping assets/openbrain-capture.rule.md into its .claude/rules/ — security-conscious repos stay off by default. It is deliberately not a hook, because deciding what is worth capturing is a judgment task. A dedicated sanitizer strips the mechanically-detectable credential/PII classes (API keys, JWTs, bearer tokens, username-bearing paths, connection strings, internal hostnames) before anything leaves the repo, enforced by a 59-assertion seeded-secret gate. Durable lesson: a redaction self-audit must detect a superset of what it strips, or it certifies the very leaks it should catch.

v3.51.0 (2026-07-24)

Removed: the SpecKit dependency (SPEC-158) — /vt-c-2-plan branched on SpecKit detection and, when .specify/ existed, delegated to /speckit.* commands that were never registered in this repo — so every "SpecKit detected" branch evaluated true and the agent silently improvised the artifact. This release collapses that dead fork into one honest planning path: workflow-2-plan/SKILL.md shrinks 628 → 539 lines with the plan-checker loop and task breakdown now unconditional, while the SPEC-143 diet rules, .plan-gate.md, and the SPEC-146 anchors are preserved byte-for-byte. The unused vt-c-speckit-integration skill (128 → 127) and specify-and-validate command (32 → 31) are deleted with every count surface reconciled, and setup.sh's SpecKit pin/verify/restore machinery removed. The hand-authored constitution at .specify/memory/constitution.md stays untouched. Shipped as a MINOR bump under an explicit never-functional-exception waiver — the deleted artifacts were never invocable, so no live contract needed a deprecation window.

v3.50.2 (2026-07-23)

VisiMatch design-system contrast fix (BUG-003) — seven muted-text declarations in the visimatch reference kit were hardcoded #71717a (~3.88:1 on the #101216 surface), failing WCAG 2.1 SC 1.4.3 (AA). All seven now use the canonical var(--vt-text-muted-d) token (#A0A0A0, ~7.17:1 — clears AA and AAA), matching the visitrans/visifair kits. Zero #71717a remain in the design system; blast radius one file.

v3.50.1 (2026-07-23)

persona-select.sh reviewer silent-drop fix (BUG-004) — the deterministic reviewer selector could no longer produce kieran-python-reviewer or design-implementation-reviewer, so /vt-c-4-review's HARD non-regression gate (T3) was red on main — the exact silent-drop class T3 exists to catch. Two causes: the language block had no Python detection path at all, and design-implementation-reviewer was gated on UI_SCOPE=frontend only. Fix adds marker-based Python detection (pyproject.toml/setup.py/requirements.txt) that joins the roster additively — the TS reviewer is suppressed only when the diff is known non-TypeScript, so a mixed monorepo and an unknown diff both keep both language reviewers — plus the conservative ! $diff_known branch for the design reviewer. Companion surfaces (persona-catalog, review-skill table, orchestrator dispatch) reconciled so the selector's spec-twin cannot drift. Tests 18 → 21 green.

v3.50.0 (2026-07-23)

Definition of Ready & Definition of Done at spec definition (SPEC-160) — names and wires the toolkit's existing entry/exit bars as two consolidated, spec-carried checklists, adding no competing gate. A single canonical source (docs/concepts/definition-of-ready-and-done.md) defines both and the honest per-item split: machine-checked items (clarity/Trennschärfe and planner-readiness via the SPEC-155 birth-gate; review-gate, test-gate, change-ledger) versus author-attested/advisory ones. spec-from-requirements now renders ## Definition of Ready + ## Definition of Done into every new spec.md (never retro-mutating the ~139 legacy specs), both it and shape emit a soft split-labeled DoR: PASS/WARN line, and 5-finalize hard-verifies the mechanical DoD items while reporting the narrative ones as advisory. An anti-drift test derives the ID→classification map from the reference doc and pins all three consumers to it.

v3.49.0 (2026-07-23)

Structural-Quality Screen for Skills (SPEC-162) — a new advisory, stdlib-only skill (vt-c-skill-structural-screen, 127 → 128 skills) scores every deployed skill against the mechanically-checkable subset of Anthropic's "Checklist for effective Skills" — orthogonal to SPEC-156's empirical keep/retest/retire axis. It consumes SPEC-156's skill-audit-inventory.json rather than re-walking the manifest, and runs five mechanical checks per skill: description sharpness (behind a HARD calibration gate), SKILL.md size ≤500 lines, bounded reference-nesting depth, anchored absolute-date detection, and backslash-path hygiene. It emits a per-skill table, a library-wide ranking of the most common failures plus a testing-debt tally, and an explicit manual-review-only block for the non-mechanical items — but writes no keep/retest/retire verdict, staying strictly separate from the value axis. Deterministic, no model calls.

v3.48.2 (2026-07-23)

Unified Plan-Metadata Contract in plan.md (SPEC-146) — downstream agents navigated plan.md partly by line number instead of a stable anchor, and a plan's maturity (requirements-gathered vs. implementation-ready) was implicit with no machine-readable field. So /vt-c-2-plan now emits two readiness signals into every newly-generated plan — an artifact_readiness frontmatter field and a stable ## Goal Capsule heading — and flips readiness to implementation-ready once the plan is complete, giving agents and gates a field to read instead of a line to count. The load-bearing fix was correcting SPEC-143's frozen "no legacy plan.md may change" gate so it stops flagging the very spec that extends the plan.md contract: the gate now ignores a spec's own newly-added plan.md (via --diff-filter=MD) while still catching any real modification of a legacy file, proven by a paired must-pass/must-fail guard sharing the gate's own predicate. Existing plan.md files stay byte-identical; tests 27/27. No new skill or agent — skill count stays at 127. The durable lesson — a class-wide invariant gate must exempt the triggering spec's own new artifact — is captured as a pattern.

v3.48.1 (2026-07-22)

Test-First Enforcement in the automatic review path (SPEC-159) — the toolkit owned a tdd-compliance-reviewer agent and a test-driven-development skill, but /vt-c-4-review's deterministic selector never actually selected the reviewer — so the automatic review path silently skipped test-first checking on every code review, while the build checklist softened the bar ("tests first or alongside code") in contradiction of the skill's Iron Law. So the reviewer is now wired into the selector's code-core: it runs whenever code is a deliverable type (including on unknown diffs — conservative — and never on non-code deliverables). It is advisory by construction — findings cap at Medium, it never writes a blocking review verdict, and an inconclusive read resolves to compliant. A review pass caught that the roster change had landed only in the selector and not in its three declared companion surfaces (the persona-catalog spec-twin, the review-skill's reviewer table, and its triage-ID prefix table); all four now agree. The build checklist bar was reconciled to the enforceable same-commit bar and cross-referenced to the Iron Law as the same bar, not a softening. A HARD calibration-promotion gate keeps the reviewer advisory until it is measured against a labeled corpus with a false-positive budget. No new skill or agent artifact, so the skill count stays at 127.

v3.48.0 (2026-07-22)

Spec-Clarity Birth Gate — /vt-c-spec-check (SPEC-155) — an under-specified or non-distinct term in a fresh spec silently mis-steers a downstream planning agent, which assumes a meaning and "turns the wrong way", with nothing catching the ambiguity at spec-creation time. So a new report-only, soft skill (always exits 0, never blocks) reads a spec for planner-readiness before it enters the workflow. Three layers: L1 reuses the existing gray-area heuristic unchanged; L2 adds a terminology watchlist with ## Begriffe glossary suppression, owned by a wrapper so Given/When/Then acceptance criteria and meta-TBD references stop firing false signals; L3 a planner-readiness rubric (misdirection risk, verdict, quote-anchored wrong-turns, proportional anchor-gaps) calibrated against a 7-spec labeled corpus as a HARD gate. It auto-hooks into /vt-c-spec-from-requirements and is surfaced via a /vt-c-dev-start nudge for the manual-workflow population that never reaches /vt-c-2-plan. Skill count 126 → 127.

v3.47.1 (2026-07-22)

Design-system control + legal-text contrast (SPEC-157 follow-up, WCAG AA) — two pre-existing contrast failures were deferred out of SPEC-157's polarity scope and landed as a quickfix. Interactive-control boundaries (.tbtn, .btn-outline) were as low as 1.22:1, below the 3:1 minimum, so a dedicated --control-border token (≈3.6:1 on dark, ≈3.24:1 on light) was added across all three theme blocks, leaving the decorative border untouched. Footer .legal text at #71717a (4.02:1) was lifted to #82828a (~5.1:1) in the visitrans and visifair kits; the visimatch label reuse is tracked separately as BUG-003.

v3.47.0 (2026-07-22)

Theme polarity is a surface property, not a brand property (SPEC-157) — the design system encoded theme as a property of the brand ("VisiMatch dark, VisiTrans/VisiFair light"), which the brand owner confirmed is wrong: every VisiTrans brand website is dark. The error had propagated out of documentation and into generation logic, so every generated VisiTrans/VisiFair prototype started in the wrong theme. So theme was re-axed to a surface→theme model across visitrans-design-system, pd-3-prototype, and kw-prototype: marketing websites, presentations, and logged-out product UI are dark; logged-in product UI is user-switchable; Word/PDF stay white. The stylesheet now ships dark as the default with light as an explicit opt-in that wins on specificity (not source order), and deliberately no prefers-color-scheme query that would leak the OS signal onto dark-only marketing surfaces. The durable lesson — a no-flash, framework-safe theme switcher — is captured as a pattern.

v3.46.0 (2026-07-21)

Skill Audit — Evaluability Inventory (SPEC-156, Wave 1) — SPEC-098 shipped the machinery to measure whether a skill earns its keep (running a task with and without the skill, comparing pass-rate and judge-score), but nothing turned those measurements into a decision, and nobody knew how much of the toolkit was even measurable. So /vt-c-skill-audit now sweeps every skill in the deploy manifest and sorts each into exactly one of four buckets: evaluated, auto-keep-private-data (it supplies knowledge the model cannot have — brand assets, internal conventions), auto-keep-toolkit-internal (plumbing), or not-evaluable. The first sweep is sobering and is the point of Wave 1: 3 evaluated, 10 private-data, 12 toolkit-internal, 101 not-evaluable of 126 skills — 2.4% eval coverage. That is the ground truth a keep/retest/retire policy needs before it can exist. Output is reproducible docs/skill-audit-inventory.md/.json plus an advisory pre-commit check; the generator always exits 0 and never gates a commit. The auto-keep predicate lives only in the generator and is pinned by 8 fixtures covering both its true and its false positives — including a binary-skip guard so a marker byte-sequence inside a PNG cannot smuggle a skill into auto-keep. Wave 2 (the decision policy and the skill-demote sweep) is deliberately unbuilt behind a stated gate of ≥20 evaluated skills across ≥3 categories — the policy would have nothing to consume today.

v3.45.0 (2026-07-06)

Cross-Project Overlap & Contradiction Detection at spec creation (SPEC-132) — New specs were authored in isolation with no automatic check for existing siblings, so overlaps (two specs touching the same surface — a missed bundling opportunity) and contradictions (a behavior another spec already defined differently — an implementation divergence) surfaced only by luck (motivating incident: a developer built a ticket detail divergently for lack of cross-ticket visibility). So /vt-c-spec-from-requirements now runs a deterministic best-effort pre-filter, sibling_scan.py, over the existing spec corpus before you approve a new spec. It ranks candidates by toolkit-native structural signals — shared depends_on, explicit SPEC-ID mentions, shared vt-c-* skill mentions, tags, and title-token Jaccard — behind a two-tier anti-wallpaper emission gate and a status denylist, emits a ranked top-5, and the skill classifies each as overlap or contradiction and offers a non-blocking prune. Survivors are written as an annotate-only ## Sibling-Candidates section on the new spec — sibling specs are never mutated; the human decides whether a relationship matters. It degrades to nothing and never gates spec creation. Scope is overlap + structural contradiction only; pure-semantic divergence is out of scope pending an embedding index. The review also surfaced and fixed a block-style-YAML frontmatter-parsing bug (docs/solutions/patterns/regex-frontmatter-block-list-swallow.md), ported to activate/scripts/shape-worthiness-score.py.

v3.44.0 (2026-07-05)

Registration check in workflow entry points (SPEC-150) — It was easy to start toolkit work on a project and forget to register it in intake/projects.yaml, and an unregistered project's learnings never reach the toolkit — /vt-c-project-sync and the default /vt-c-toolkit-review read only that registry. The existing soft "Step 0.5: Project Registration Check" had holes landing exactly on a new project's first steps: four entry points (activate, spec-from-requirements, quickfix, session-journal) had no check; the trigger only fired once CLAUDE.md/.design-state.yaml already existed, so a brand-new project was silently skipped; "Skip for now" could be dismissed forever with no escalation; and a $PWD substring match made worktrees read as unregistered and nag. So we moved all the logic into one script, check_registration.sh (single source of truth), invoked from an import-like stub in all 11 entry-point skills. The trigger no longer needs pre-existing toolkit artifacts, worktrees resolve to their registered parent via longest-prefix match, and "Skip for now" is remembered and escalates. We also reconciled a path drift where scaffold dropped proposals into a folder the sweep never scanned. The two context: fork hosts (4-review, 5-finalize) stay fork-safe — they still invoke the shared script but report instead of prompting, a pattern captured in docs/solutions/patterns/fork-safe-single-source-stub.md. 25/25 tests.

v3.43.1 (2026-07-05)

Claude Code usage monitoring (SPEC-129) — There was no way to see how Claude Code was performing for you — cache efficiency, token cost, which skills and tools you actually invoke — and the full Prometheus/Grafana stack originally envisioned is disproportionate at a ~4-developer scale. So we shipped a zero-infrastructure, on-demand local readout: python3 configs/monitoring/cc-metrics.py parses the session logs Claude Code already writes under ~/.claude/projects/ and prints the cache-read ratio (the key signal), token totals, and per-tool/per-skill counts. It reads numbers and names only — never the contents of your prompts, responses, or tool calls (enforced by a privacy test that seeds a secret and asserts it can never appear). An optional, opt-in deep-mode (otel-receiver.py + settings.otel.json.patch) captures authoritative token totals over a loopback-only OpenTelemetry receiver that strips identifying attributes before writing. The full team-aggregate stack is preserved as a demand-gated upgrade path in docs/operations/monitoring.md. See the monitoring guide.

v3.43.0 (2026-07-04)

Dev-focused discoverability (SPEC-149) — The toolkit grew to 125 skills, and the sole entry point (/vt-c-0-start) is workflow-oriented rather than persona-oriented, so Dev-persona colleagues de facto weren't using it. We added /vt-c-dev-start — an entry-point skill that surfaces six task-based skill landmaps (plus show-all) so you find the right skill by what you want to do — plus role/task getting-started docs (docs/getting-started/by-role.md, by-task.md) wired into the site nav. Empirical adoption evaluation (US-3) is deferred to 2026-08-01 before any further plugin extraction.

v3.37.1 (2026-05-18)

Supply-Chain Security Hook (SPEC-139) — New supply-chain-guard.sh PreToolUse hook intercepts 12 package-manager install patterns (npm, pnpm, yarn, pip, pip3, pipx, uv, poetry) before they execute. Each package is checked against the osv.dev CVE batch API and the OSSF Malicious Packages registry. CVE hits and OSSF matches hard-block the install and return a structured denial message to the model. Fail-closed: when both APIs are unreachable, the install is blocked (override: VTS_ALLOW_OFFLINE=1). Single-source-offline scenarios log result=partial-allow for auditable coverage tracking. Private/scoped packages bypass OSSF and log result=unchecked-private. All intercepted installs (blocked, allowed, or overridden) are appended to ~/.claude/security-hook.log in JSON-lines format suitable for ISO 27001 audit trails. Registered in hooks.json (priority 78, 30s timeout) and SHA-256-registered in configs/security/trusted-hooks.yaml. Skills /vt-c-npm-security and /vt-c-python-security updated to reference the hook. 39-test suite at tests/test-supply-chain-hook.sh (fully mocked, no network).

v3.37.0 (2026-05-15)

VMS Numbered CWP Workflow (SPEC-139 VMS) — The VMS plugin had 8 skills and 6 agents but no enforcement to prevent skipping steps. Large CWPs (88 files) required multiple sessions with no way to track per-file progress or resume. A numbered 5-step workflow now gates each transition: Step 1 (activate) initialises tracking, Step 2 (plan) writes a soft .cwp-plan-gate.yaml, Step 3 (draft) tracks per-file progress and writes .cwp-checkpoint.yaml at batch boundaries, Step 4 (review) writes a hard .cwp-review-gate.yaml, and Step 5 (complete) enforces a GO/NO-GO quality gate before marking done. The new /vt-v-draft skill (Step 3) routes between interactive interview mode and batch write mode. Session resume is script-backed: start_scanner.py now reads .cwp-checkpoint.yaml directly and surfaces it as the highest P0 action — checkpoint detection no longer depends solely on Claude following the SKILL.md instruction.

Review-to-Task Pipeline (SPEC-140 VMS, Phase B) — Document review in Obsidian produced gaps needing tracking (e.g., "hire a Betriebsarzt") but [!todo] callouts were lost. todo_scanner.py now scans all vault content directories for [!todo] callouts and matches them against existing aufgaben using title and quelle fields. Unlinked findings surface in the /vt-v-start session dashboard. Deduplication via <!-- aufgabe: review-YYYY-MM-DD-NNN --> comment pattern prevents double-tracking.

v3.33.0 (2026-04-22)

GitHub Issue Intake (SPEC-116) — Colleagues can now file issues on GitHub and have them flow automatically into the toolkit's intake pipeline. /vt-c-inbox-qualify gained Step 0, which fetches open GitHub issues, imports new ones into intake/inbox/, and tracks new comments on already-processed issues via comment IDs (structural diff, not heading counts). Issues are mapped to intake frontmatter by their GitHub labels: bug → workflow-defect / high, enhancement → missing-capability / medium, documentation → missing-pattern / low. Use --no-github to skip the sync for offline qualification.

Security-hardened import path — Imported GitHub content is treated as untrusted: body and comment text are wrapped in ~~~text fences so embedded SYSTEM: framing or [x] checklists cannot steer Claude downstream, filename slugs are built from an allowlist (no path traversal), issue numbers are validated as ^[0-9]+$ before shell use, YAML frontmatter values are JSON-encoded (no YAML injection), and a regex scanner redacts API keys / tokens / JWTs / bearer tokens / private keys to [REDACTED] before anything lands in intake/. Repo URL is derived from gh repo view so the skill works in any project that installs core-standards.

Renumbering: this spec started life as SPEC-050 and was renumbered to SPEC-116 to resolve a collision with the original SPEC-050 (namespace-convention, shipped 2026-03-06). Commit messages on the feature branch still reference SPEC-050.

v3.31.0 (2026-04-20)

Security baseline hardening (SPEC-114) — The security baseline grew from 5 categories / ~20 deny rules to 11 categories / ~128 deny rules. Six new categories close governance gaps that prior CLAUDE.md instructions failed to enforce: git safety (force push / hard reset / clean -f), inline code execution (python -c / node -e), database destructives (DROP / ORM reset), infrastructure teardown (terraform destroy / namespace delete), self-modification protection (global ~/.claude/ files and .git/), and agent governance (--dangerously-skip-permissions, crontab, audit-log removal).

Notable additions: - Category 2 bypass closed — Grep and Glob mirrors now block the credential-read bypass that existed when only Read(**/.env) was denied. .env variants enumerated so .env.example remains readable (EC-01). - .claudeignore now actually enforced — Claude Code does not natively honor .claudeignore; the new claudeignore-guard.sh PreToolUse hook closes that gap. - Pre-commit fail-closed — the pre-commit hook now blocks staged .env files and invokes secret-scanner.sh on every staged file, failing the commit (with install instructions) if the scanner is missing rather than silently skipping. - Scaffold and bootstrap now generate .claudeignore for all project types and .gitleaks.toml for coding/mixed projects. The gitignore-base template gained .env entries that were previously missing for knowledge and design projects.

See SECURITY-CONFIG.md for the full threat model per category.

v3.30.0 (2026-03-30)

Recursive criticism gate (SPEC-105) — New /vt-c-recursive-criticism skill runs 1–3 focused self-review passes (security, error handling, edge cases) before the multi-agent code review, plus a pre-review ritual integrated into /vt-c-3-build.

Autoresearch optimization agent (SPEC-106) — New /vt-c-autoresearch-agent skill implements Karpathy's single-metric optimization loop: measure baseline, hypothesize, implement, measure, accept (git commit) or reject (git revert), repeat with configurable iteration budget and convergence detection.

Also in this release

• Quality metrics integration (SPEC-109) — optional Step 5.8 in /vt-c-4-review auto-detects coverage tooling (nyc, c8, pytest-cov, go cover, SimpleCov), captures line/branch coverage, detects regressions over 2%, and writes results into the review gate (3.30.1)
• Build verification loop (SPEC-108) — /vt-c-3-build Step 6.5a runs an auto-detected test command up to 5 iterations until convergence; --skip-verify available (3.30.1)
• Dream + Open Brain consolidation (SPEC-107) — /vt-c-dream extends auto-memory consolidation to Open Brain persistent thoughts (3.30.1)
• Playwright E2E integration (SPEC-110) — /vt-c-4-review Step 5.9 auto-runs Playwright for ui_scope: frontend or mixed specs, captures screenshots into the spec directory, and includes results in the review gate (3.30.2)
• Phase checkpoint integration (SPEC-111) — all four phase skills auto-read on entry and auto-write on exit, enabling clean conversation clearing between phases (3.30.3)
• Auto-compound on spec completion (SPEC-112) — /vt-c-complete Step 4.6 prompts for compound knowledge capture before marking specs done; auto-skips trivial specs (3.30.4)

v3.28.0 — v3.29.0 (2026-03-27)

Memory consolidation skill (SPEC-102, 3.28.0) — New /vt-c-dream skill performs reflective consolidation of Claude Code auto-memory files: detects stale dates, dead references, contradictions, and duplicates with human confirmation for uncertain deletions.

Remotion video generation (SPEC-099, 3.29.0) — New /vt-c-remotion-video skill generates programmatic videos via Remotion using a structured interview-then-generate pattern, intended for VisiTrans product demos and explainer content.

Also in this release

• Security hardening (SPEC-103) — pinned MCP package versions in setup.sh, integrity hash verification (setup.sh --verify), Open Brain sanitization rule in CLAUDE.md, intake input validation in /inbox-qualify, SKILL.md tool-declaration audit, default npm ci --ignore-scripts, branch protection check in /repo-health, and a new security documentation set (overview, hardening, incident response) (3.29.1)
• Memory consolidation enhancement (SPEC-104) — /vt-c-dream cross-references .design-state.yaml to detect stale memory entries referencing completed specs (3.29.1)

v3.27.0 (2026-03-27)

Skill testing & benchmarking framework (SPEC-098) — New /vt-c-skill-eval skill runs YAML-based eval test cases against skills using a quality-grader agent. Ships with 15 eval cases across vt-c-2-plan, vt-c-4-review, and vt-c-spec-from-requirements, plus eval infrastructure under tests/evals/.

Also in this release

• VisiTrans design system canonical token source (SPEC-101) — five SKILL.md files and two brand_colors.py scripts now reference the canonical YAML token source instead of hardcoded values (3.27.1)
• Skill prefix corrections (SPEC-097) — intent-skill-matcher and postcompact-recovery migrated from stale vt-i-* to vt-v-*; skill linter quick_validate.py gained prefix-aware name validation (3.26.1)

v3.26.0 (2026-03-24)

Workflow gate enforcement (SPEC-095) — Persistent gates added across all four phases: /vt-c-2-plan writes plan_gate, /vt-c-3-build writes build_gate, /vt-c-4-review writes review_gate, and /vt-c-5-finalize writes finalize_gate — all into specs/[N]-feature/state.yaml as committed YAML. /vt-c-complete Step 2.5 verifies all four gates before allowing completion. Emergency bypass is available but recorded permanently in state.yaml. Backed by global CLAUDE.md Rule 16 (Workflow Gate Enforcement).

v3.25.0 (2026-03-24)

Weekly planning skill — New /vt-c-weekly-planning skill drives a structured weekly planning session via Open Brain task management MCP tools: Asana sync, grouped task dashboard, interactive review/reschedule, new task creation, decision capture, and an Obsidian weekly review summary (SPEC-094).

v3.22.0 — v3.24.0 (2026-03-24)

User manual generation pipeline (SPEC-090, SPEC-091, SPEC-092) — Three skills compose a documentation lifecycle that follows code from PRD through implementation:

• /vt-c-user-manual-generate (3.22.0) auto-generates a complete MkDocs user manual from a PRD with one page per feature, step-by-step usage, states, edge cases, and screenshot placeholders. /vt-c-pd-2-prd Step 8.5 prompts to generate after PRD completion; /vt-c-pd-6-handoff includes the link in its handoff README.
• /vt-c-user-manual-update (3.23.0) auto-generates draft updates to manual pages when a spec is completed; spec-to-docs mapping uses a docs_page field in spec state.yaml. /vt-c-complete prompts after spec completion.
• User manual build gate (3.24.0) — /vt-c-5-finalize Step 2.5 runs mkdocs build --strict against docs/user-manual/, blocks on failures, detects <!-- DRAFT --> markers, and reports documentation coverage. Same release added auto-version-bump in /vt-c-5-finalize Step 0c (MINOR/PATCH detection bumps registry.json, plugin.json, and CHANGELOG.md instead of blocking).

v3.20.0 (2026-03-23)

Bug intake pipeline (SPEC-016) — New /vt-c-bug-report and /vt-c-triage-bugs skills handle structured bug intake with auto-numbered BUG-NNN files, severity classification, and screenshot support. Promote / defer / duplicate triage uses git mv to preserve history. /vt-c-activate recognises BUG-NNN and creates fix/bug-NNN-* branches; /vt-c-complete detects those branches and updates bug state to verified. /vt-c-investigate-bug accepts a BUG-NNN argument and passes the report to the bugfix-orchestrator.

v3.19.0 (2026-03-22)

Repository evaluation safety protocol (SPEC-079) — New /vt-c-repo-evaluate skill assesses external GitHub repositories using a 4-level safety protocol: API-only analysis by default (Level 1), escalation-gated safe clone with hook inspection (Level 2), Docker sandbox and dependency audit guidance (Levels 3–4). Documented as a new section in the security governance guide.

Also in this release

• Removed unsupported allowed-tools frontmatter field from 20 SKILL.md files
• Optional from: field added to externalRelationships for C4 container view (overrides default last-declared-container routing)

v3.18.0 (2026-03-19)

Pre-PR simplify ritual (SPEC-081) — Added a /simplify reference guide with focused-mode syntax, a pre-PR ritual, and skip conditions. The code-simplicity-reviewer agent now respects the "What NOT to Change" sections added to four CLAUDE.md templates so protected patterns are not flagged. Advisory tips for the simplify ritual now appear in /vt-c-4-review PASS output and /vt-c-5-finalize GO output.

v3.17.0 (2026-03-19)

Intent engineering for skills and agents (SPEC-080) — Added an intent engineering checklist (references/intent-engineering-checklist.md) and applied Intent Boundaries sections to all six active orchestrators and three template agents (toolkit-developer, ims-writer, docs-pipeline). Five fork-context skills (workflow-4-review, workflow-5-finalize, pd-4-validate, mermaid-to-images, container-logistics-ux-expert) gained Intent Constraints sections. The audit-skill workflow now includes an intent engineering audit step.

v3.16.0 (2026-03-18)

Advanced diagram generation (SPEC-077) — Two new capabilities for diagram workflows:

• Format auto-selection: vt-c-mermaid-diagrams-branded now counts diagram elements and warns when Mermaid's Dagre layout may struggle. Under 10 elements: proceed; 10–15: ask user; over 15: recommend PlantUML.
• C4 from YAML (/vt-c-c4-diagram): Generate branded C4 context and container diagrams directly from c4: YAML frontmatter in system notes — no manual Mermaid authoring. Supports actors, containers, external systems, and typed relationships. VisiTrans brand colors applied automatically.

v3.15.0 (2026-03-18)

Strategic mentor review agent (SPEC-075) — Added strategic-mentor agent that provides VIABLE / NEEDS REVISION / FLAWED verdicts on plans and specs before build begins. Dispatched in parallel with plan-checker in /vt-c-2-plan Step 4.5 (informational, non-gating).

v3.9.0 (2026-03-08)

Hook security audit (SPEC-053) — Repo audit had no way to detect tampered, unauthorized, or rogue hook scripts. Added checksum verification, unknown hook detection, network call scanning, and permission checks against a trusted hooks manifest (configs/security/trusted-hooks.yaml) with SHA-256 checksums for all 23 hook scripts.

Also in this release

• Wave-based dependency execution (SPEC-054) — parallel wave scheduling in /vt-c-activate and /vt-c-3-build
• Visual reference enforcement (SPEC-056) — design implementation verification
• Security review pipeline (SPEC-028) — structured security review workflow
• /vt-c-complete skill split from /vt-c-activate --complete for dedicated spec completion
• Deploy→finalize rename across all active files

v3.8.0 (2026-03-06)

Namespace convention (SPEC-050) — Skills, commands, agents, and hooks from the toolkit collided with identically-named artifacts from external plugins (compound-engineering). Applied vt-{p}-{name} namespace to all 102 skills, 37 commands, 54 agents, and 7 hooks. Created agent symlink manifest and manifest-based deployment in setup.sh.

Documentation refresh (SPEC-048) — Documentation had drifted from actual toolkit state across five gap categories. Updated component counts, completed all symlink manifests, added missing guides (security governance, composable skills, contributing), created plugin READMEs, and integrated architecture docs into the MkDocs site.

Also in this release

• Worktree-aware phase transitions (SPEC-040) — workflow skills detect and switch to correct worktrees
• Plan-checker validation loop (SPEC-042) — automated plan validation up to 3 iterations in /vt-c-2-plan
• Adopted 3 orphaned hooks into governed plugin manifests
• Cleaned up 8 orphaned agent files and 6 orphaned skill artifacts from ~/.claude/

v3.7.0 (2026-03-04)

GSD wave execution (SPEC-036) — Added wave-grouped dashboard to /vt-c-activate, parallel opportunity detection in /vt-c-3-build, and pre-plan /vt-c-shape skill for dependency-aware execution.

Agent architecture patterns (SPEC-044) — Created reference documentation for CC 2.1 patterns (skill hooks, policy islands, fork semantics, orchestrators) with examples and pitfall guidance.

Configuration drift audit (SPEC-046) — Extended /vt-c-repo-health to detect security configuration drift from baseline snapshots, flagging weakened deny rules and MCP server sprawl.

Also in this release

• Document placement strategy (SPEC-038) — docs-only changes stay on current branch, eliminating visibility gaps
• Beads activation (SPEC-034) — distributed issue tracker replaces file-todos for persistent work-item tracking

v3.6.0 (2026-03-03)

Security hardening (SPEC-035) — Established security baseline configs for Claude Code settings with deny rules and MCP whitelisting audit integration into /vt-c-repo-health.

CWP pre-PR checks (SPEC-037) — Automated pre-PR validation for CWP lifecycle with must-pass checks (MkDocs build, YAML frontmatter, no broken wikilinks) integrated into /vt-v-cwp.

Also in this release

• UFI country enrichment pipeline (SPEC-039) — added country enrichment to /vt-u-sync for contacts and companies with confidence scoring

v3.5.0 (2026-03-02)

Skill permission governance (SPEC-029) — Addressed approval fatigue in long sessions by adding skill-to-agent permission binding, autonomy hooks for continuation decisions, and pre-authorized agent templates.

Skill quality assurance (SPEC-031) — Added pressure-test validation to skill-creator and spec-compliance review as a prerequisite to code quality checks, preventing untested and spec-drifted implementations.

v3.4.0 (2026-03-01)

Intelligent skill activation (SPEC-030) — Skills were forgotten after context compaction, hook matchers couldn't filter by file path, and there was no intent-based skill suggestion. Added three-layer skill amnesia mitigation (CLAUDE.md inventory, PreCompact hook, post-compaction recovery), a reusable path-match.sh utility for file-path filtering in hook scripts, and a UserPromptSubmit intent matcher that suggests relevant skills based on user input keywords.

Agent worktree isolation (SPEC-032) — Write-capable agents running concurrently could cause branch contamination. Audited all 58 agents and added isolation: worktree to 9 qualified agents. Updated agent creation guidelines with a 4-question isolation decision checklist.

Also in this release

• Fixed vault-write-guard.sh to read from stdin JSON (was using unimplemented $CLAUDE_TOOL_INPUT)
• Deployed path-match.sh symlink to ~/.claude/hooks/ for hook script reuse
• Skill inventory (67 skills) added to user-global CLAUDE.md (Part 5)
• Skill amnesia mitigation pattern documented at docs/solutions/patterns/

v3.3.0 (2026-02-27)

Finalize gate version enforcement (SPEC-023) — Releases could proceed without version bumps or changelog entries, causing silent drift between what was finalized and what documentation reflected. Added check-finalize-versions.sh that blocks /vt-c-5-finalize when version bump or changelog entry is missing for changed plugins.

Session start notifications (SPEC-022) — Users had no visibility into plugin version changes between sessions. Added a startup hook that compares registry versions against last-seen state and shows version diffs with top changelog entries for context.

Review auto-fix loop (SPEC-024) — Code reviews often returned findings that were mechanically fixable, adding friction. Added auto-fix loop to /vt-c-4-review that classifies findings as [AUTO-FIXABLE] or [HUMAN-REQUIRED] and applies mechanical fixes up to 2 iterations before surfacing remaining issues.

Documentation sync skill — Created /vt-c-doc-sync to audit documentation against actual toolkit state. Checks component counts, terminology, version references, and macros. Maintains a change ledger capturing the "why" behind each change.

Also in this release

• Plugin versioning guide at docs/guides/plugin-versioning.md
• CHANGELOG.md requirement in creating-plugins guide
• Change ledger (docs/change-ledger.md) with entries for SPEC-020 through SPEC-024

v3.1.0 (2026-02-25)

IMS plugin extraction (SPEC-021) — The core-standards plugin had grown to include IMS agents and skills only relevant to compliance workflows. Extracted 6 agents and 6 skills into an independent ims plugin with its own metadata and changelog.

v3.0.0 (2026-02-14)

Multi-plugin architecture — The monolithic plugin structure couldn't support department-specific tooling. Introduced per-plugin .claude-plugin/ directories, plugins/registry.json as version authority, and setup.sh --plugins flag for selective installation.

Two-workflow architecture — Harmonized from three-workflow to two-workflow per constitution v1.0.0: Unified Product Development and Knowledge Work.

Also in this release

• Finance department plugin as separate optional plugin
• --list-plugins command for plugin discovery
• /vt-c-content-evaluate skill for deep knowledge gap analysis
• 13 legacy docs files removed (superseded by MkDocs site)

v2.1.0 (2026-02-12)

• Product Design workflow (/vt-c-pd-0-start through /vt-c-pd-6-handoff)
• Knowledge Work workflow (/vt-c-kw-0-start through /vt-c-kw-4-publish)
• Research ingestion system (/vt-c-research-ingest, /vt-c-research-implement)

v2.0.0 (2026-02-10)

• Numbered workflow sequence /vt-c-0-start through /vt-c-6-operate
• Session journal and session consolidator for continuous knowledge capture
• Production-ready components: incident response, continuous learning, quality infrastructure

---

Full changelog | Change ledger