@osovv/vv-opencode 0.35.28 → 0.35.30

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (10) hide show
  1. package/CHANGELOG.md +30 -0
  2. package/README.md +99 -77
  3. package/dist/lib/vvoc-preset-registry.d.ts +11 -1
  4. package/dist/lib/vvoc-preset-registry.js +10 -0
  5. package/dist/lib/vvoc-preset-registry.js.map +1 -1
  6. package/package.json +2 -2
  7. package/schemas/vvoc/v3.json +1 -1
  8. package/templates/agents/vv-controller.md +1 -1
  9. package/templates/skills/vv-plan/SKILL.md +1 -1
  10. package/templates/skills/vv-spec/SKILL.md +5 -5
package/CHANGELOG.md CHANGED
@@ -1,9 +1,39 @@
1
+ ## <small>0.35.30 (2026-06-24)</small>
2
+
3
+ ### Summary
4
+
5
+ Spec packages created by the vv-spec skill now use date-prefixed directory names (YYYY-MM-DD-slug) so active packages sort by creation date and are easier to identify, with corresponding updates to the vv-spec, vv-plan, and vv-controller skill and agent templates. The project documentation has been fully migrated to the GRACE 4 artifact model, replacing legacy XML sources under docs/ with the current .grace/ directory structure, and all GRACE context artifacts—requirements, technology, principles, deployment, and UX guidelines—have been refined for clarity and accuracy. Legacy GRACE 3 XML documents and superseded workflow plan handoff notes have been removed, and stale migration references have been cleaned up from graph and verification indexes.
6
+
7
+ * feat(vv-spec): date-prefix spec packages ([0dba659](https://github.com/osovv/vv-opencode/commit/0dba659))
8
+ * docs: drop migration report artifact ([327812d](https://github.com/osovv/vv-opencode/commit/327812d))
9
+ * docs: finalize GRACE migration cleanup ([496236f](https://github.com/osovv/vv-opencode/commit/496236f))
10
+ * docs: migrate project to GRACE 4 ([ba3e162](https://github.com/osovv/vv-opencode/commit/ba3e162))
11
+ * docs: refine GRACE context requirements ([73245b1](https://github.com/osovv/vv-opencode/commit/73245b1))
12
+ * docs: refine GRACE deployment context ([cd2da0f](https://github.com/osovv/vv-opencode/commit/cd2da0f))
13
+ * docs: refine GRACE principles context ([ad1b050](https://github.com/osovv/vv-opencode/commit/ad1b050))
14
+ * docs: refine GRACE technology context ([eeff4d2](https://github.com/osovv/vv-opencode/commit/eeff4d2))
15
+ * docs: refine GRACE UX guidelines ([09d075a](https://github.com/osovv/vv-opencode/commit/09d075a))
16
+ * docs: remove legacy GRACE 3 artifacts ([c9b910d](https://github.com/osovv/vv-opencode/commit/c9b910d))
17
+ * docs: remove stale GRACE migration references ([6ad640a](https://github.com/osovv/vv-opencode/commit/6ad640a))
18
+
19
+ ## <small>0.35.29 (2026-06-22)</small>
20
+
21
+ ### Summary
22
+
23
+ This release adds the `vv-osovv-cheap` preset, which provides a more cost-effective set of model role assignments by combining deepseek, stepfun, minimax, and zai models, and updates the project documentation to clarify vvoc's role as a curated, opinionated plugin set that adds a structured spec-to-code process layer for safer, more portable agentic development—including formalized trajectories, review-driven execution, and long-run safety features.
24
+
25
+ * feat(preset): add vv-osovv-cheap preset with zai smart and deepseek reviewer ([dfe1efe](https://github.com/osovv/vv-opencode/commit/dfe1efe))
26
+ * docs: clarify vvoc process positioning ([3d78927](https://github.com/osovv/vv-opencode/commit/3d78927))
27
+ * docs: explain plugin user benefits ([baf716b](https://github.com/osovv/vv-opencode/commit/baf716b))
28
+ * docs: update project positioning ([7af2865](https://github.com/osovv/vv-opencode/commit/7af2865))
29
+
1
30
  ## <small>0.35.28 (2026-06-21)</small>
2
31
 
3
32
  ### Summary
4
33
 
5
34
  This release completes the strict cutover from legacy behavior: vvoc config parsing now rigidly enforces canonical schema v3 with the `plugins` section as required, rejecting old, incomplete, or malformed `vvoc.json` files instead of silently migrating or repairing them; `vvoc status` and `vvoc doctor` report parse errors without mutating the file, and `vvoc upgrade` treats a failed post-install sync as a reported partial upgrade requiring manual config fix. Runtime compatibility fallbacks have been removed — Guardian permission replies use only the current OpenCode permission API or HTTP reply, Hashline edit anchors accept only current hashing algorithms, and `vvoc sync` no longer deletes old managed-agent names or managed command entries, leaving them untouched while writing current registrations. Users with existing v1/v2 configs must manually update to schema v3 before any sync, install, or plugin runtime will proceed.
6
35
 
36
+ * feat(preset): add vv-osovv-cheap preset with zai smart and deepseek reviewer ([c2b7fb0](https://github.com/osovv/vv-opencode/commit/c2b7fb0))
7
37
  * docs: complete launch polish pass ([b026a79](https://github.com/osovv/vv-opencode/commit/b026a79))
8
38
  * docs: document strict legacy cutover ([cf99ccf](https://github.com/osovv/vv-opencode/commit/cf99ccf))
9
39
  * feat(config): enforce strict vvoc config parsing ([299a398](https://github.com/osovv/vv-opencode/commit/299a398))
package/README.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # @osovv/vv-opencode
2
2
 
3
- **Portable OpenCode workflow toolkit** — one command bootstraps a managed agent ecosystem, skill-driven spec-to-code pipeline, security-and-productivity plugins, and a unified CLI.
3
+ **Curated, opinionated OpenCode plugin set** for spec-first, review-driven, safer agentic development — with managed agents, skills, safety plugins, and the `vvoc` CLI.
4
4
 
5
5
  <p>
6
6
  <a href="https://www.npmjs.com/package/@osovv/vv-opencode"><img src="https://img.shields.io/npm/v/%40osovv%2Fvv-opencode?style=flat&label=npm&color=blue" alt="npm"></a>
@@ -37,44 +37,62 @@ Project scope writes only to `./.opencode/` and `./.vvoc/`. A normal `opencode`
37
37
 
38
38
  ## Spec-to-Code Pipeline
39
39
 
40
- The core workflow is a three-stage pipeline with independent review gates at each level. All artifacts for one feature live in a single spec package directory:
40
+ vvoc keeps larger agentic work from jumping straight into edits. The process turns a request into explicit artifacts first, then executes the approved plan with bounded implementation and review loops.
41
41
 
42
42
  ```
43
- User request
44
- │
45
- ▼ auto-trigger
46
- vv-spec ───────────────────────────────────────→ .vvoc/specs/<id>/spec.xml
47
- │ Grill-me interview (one question at a time)
48
- │ Decision tree with recommended answers
49
- │ Deep synthesis by expensive model (no sub-agent delegation)
50
- │ Optionally creates .vvoc/specs/<id>/design-context.xml
51
- │ for complex sessions (design memory, not requirements)
52
- │
53
- ├── ① Spec review: requirements correct, complete, unambiguous?
54
- │
55
- ▼ auto-trigger (after approval)
56
- vv-plan ───────────────────────────────────────→ .vvoc/specs/<id>/plan.xml
57
- │ Reads sibling design-context.xml when present (explanatory only)
58
- │ Interface contracts with JSDoc behavior descriptions
59
- │ Acceptance criteria per task (grep: `<criterion>`)
60
- │ Dependency ordering (grep: `<task_id>`)
61
- │ Three-layer review model: spec → plan → code
62
- │
63
- ├── ② Plan review: every spec requirement → task? Contracts match spec?
64
- │
65
- ▼ auto-trigger (after approval)
66
- vv-implementer → vv-spec-reviewer → vv-code-reviewer
67
- │ Workflow tracked loop with work items
68
- │ Spec review checks: code matches spec?
69
- │ Code review checks: implementation matches plan contracts?
70
- │
71
- ├── ③ Code review: interfaces correct? All AC pass?
72
- │
73
- ▼
74
- Done
43
+ Request / idea
44
+ ↓
45
+ vv-spec
46
+ asks clarifying questions
47
+ writes .vvoc/specs/YYYY-MM-DD-<slug>/spec.xml
48
+ waits for spec approval
49
+ ↓
50
+ vv-plan
51
+ reads the approved spec
52
+ writes .vvoc/specs/YYYY-MM-DD-<slug>/plan.xml
53
+ defines tasks, contracts, dependencies, and acceptance criteria
54
+ waits for plan approval
55
+ ↓
56
+ vv-execute
57
+ applies the approved plan task by task
58
+ runs implementation + review internally
59
+ verifies before moving on
60
+ ↓
61
+ Verified result
75
62
  ```
76
63
 
77
- Specs and plans use a top-level lifecycle status: `draft` while being written, `approved` after explicit user approval, and `applied` after successful execution. `vv-execute` archives applied artifact packages by moving the entire spec package directory `.vvoc/specs/<id>/` to `.vvoc/specs/archive/<id>-<timestamp>/`.
64
+ Inside `vv-execute`:
65
+
66
+ ```text
67
+ Each plan task
68
+ ↓
69
+ vv-implementer
70
+ implements the focused task and runs targeted verification
71
+ ↓
72
+ vv-spec-reviewer
73
+ checks whether the result matches the approved spec
74
+ ↓
75
+ vv-code-reviewer
76
+ checks bugs, regressions, maintainability, and missing tests
77
+ ↓
78
+ verification
79
+ pass → next task
80
+ fail → bounded retry loop
81
+ needs context / blocked → stop and ask the user
82
+ ```
83
+
84
+ All artifacts for one feature live together:
85
+
86
+ ```text
87
+ .vvoc/specs/YYYY-MM-DD-<slug>/
88
+ spec.xml # what should be built and why
89
+ design-context.xml # optional design memory
90
+ plan.xml # how to implement and verify it
91
+ ```
92
+
93
+ New `vv-spec` packages use a date-prefixed id (`YYYY-MM-DD-<slug>`, for example `2026-06-24-cache-store`) so active packages sort by creation date.
94
+
95
+ Specs and plans use a top-level lifecycle status: `draft` while being written, `approved` after explicit user approval, and `applied` after successful execution. `vv-execute` archives applied artifact packages by moving the entire spec package directory `.vvoc/specs/YYYY-MM-DD-<slug>/` to `.vvoc/specs/archive/YYYY-MM-DD-<slug>-<timestamp>/`.
78
96
 
79
97
  ### XML grep
80
98
 
@@ -103,15 +121,16 @@ Managed skills are installed by `vvoc`. `vv-controller` explicitly routes `vv-sp
103
121
 
104
122
  ## Why vv-opencode?
105
123
 
106
- Setting up OpenCode for serious daily work means juggling config files, agent prompts, plugin wiring, model role assignments, and permission rules — every time, on every machine.
124
+ OpenCode is a strong, flexible base for agentic coding, but it intentionally leaves the development process mostly up to you: when to clarify requirements, when to plan, when to investigate first, when to review, and how to keep longer runs safe. That flexibility is powerful, but it can also make agent work feel loose and inconsistent.
107
125
 
108
- **vv-opencode collapses that into a single `vvoc install`.** It owns the wiring so you don't have to:
126
+ **vv-opencode adds a curated process layer on top of OpenCode:**
109
127
 
110
- - **Six plugins, one entry** — all plugins are exported from a single pinned package entry
111
- - **Managed agent & skill system** — `vv-controller` routes `vv-spec`, `vv-plan`, and `vv-review`; bundled managed skills also include `vv-execute` and `vv-reflect`
112
- - **Model roles & presets** — assign models to roles (`smart`, `fast`, `vision`, …) and switch provider presets with one command
113
- - **Security-first** — a `guardian` agent reviews permission requests, secrets are redacted from LLM-bound chat
114
- - **Stale-line-number defense** — hashline-backed `edit` prevents write-against-wrong-snapshot bugs
128
+ - **Formalized trajectories** — small changes stay direct, unclear bugs start with investigation, large changes go through spec and plan, and risky implementation uses review loops
129
+ - **Spec-first by default** — turn broad requests into explicit specs, plans, and review gates before implementation
130
+ - **Review-driven execution** — keep implementation, spec review, and code review as separate steps instead of one agent silently doing everything
131
+ - **Portable model choices** — use roles like `vv-role:smart` and `vv-role:fast` in shared agents, then map those roles per machine or project
132
+ - **Long-run safety** — Guardian auto-approves routine low-risk permission requests, leaves risky ones to OpenCode's manual approval flow, and secrets redaction reduces accidental leakage
133
+ - **Safer edits** — hashline-backed `edit` ties changes to fresh `read` output so agents are less likely to write against stale line numbers
115
134
 
116
135
  ---
117
136
 
@@ -119,28 +138,28 @@ Setting up OpenCode for serious daily work means juggling config files, agent pr
119
138
 
120
139
  | Area | What you get |
121
140
  |---|---|
122
- | **Plugins** | 6 plugins in one pinned package entry — workflow orchestration, model roles, guardian, hashline edit, system context injection, secrets redaction |
123
- | **Agent System** | `vv-controller` routes work: direct for small changes, `investigator` for bugs, implementer+reviewer loop for risky work, and `vv-spec`/`vv-plan` for large features |
124
- | **Skills** | `vv-spec` interviews you and writes an XML spec; `vv-plan` maps the spec to interface contracts and acceptance criteria; `vv-execute` runs approved plans; `vv-review` runs a review-only workflow; `vv-reflect` preserves reusable session findings as repository memory |
125
- | **Spec-to-Code Pipeline** | `vv-spec` → spec review → `vv-plan` → plan review → `vv-implementer` → code review. Three independent review gates cover requirements, contracts, and implementation |
126
- | **One-Click Setup** | `vvoc install` or `vvoc sync` bootstraps everything — config, agents, skills, prompts, presets |
127
- | **CLI Tooling** | 16+ commands: install, sync, launch, status, doctor, role management, presets, guardian config, shell completion, upgrade |
128
- | **Security** | GuardianPlugin reviews shell-permission requests; SecretsRedactionPlugin strips tokens before LLM requests; both configurable via `vvoc.json` |
129
- | **Model Roles** | Assign provider/model/variant to roles (`default`, `smart`, `fast`, `vision`, custom); switch between `vv-openai`, `vv-zai`, `vv-deepseek`, `vv-minimax` presets |
130
- | **Workflow Tracking** | Explicit-intent work items with open/list/close for tracked implementation and review-only pipelines |
141
+ | **Plugins** | A curated set of OpenCode plugins that make agentic work more structured, portable, and safer without hand-wiring each piece yourself |
142
+ | **Agent System** | A default controller that picks the right path: direct changes for small work, investigation before unclear fixes, and implementer/reviewer loops for risky changes |
143
+ | **Skills** | Guided workflows for turning ideas into specs, specs into plans, plans into execution, reviews into findings, and long sessions into reusable memory |
144
+ | **Spec-to-Code Pipeline** | A repeatable path from request → spec → plan → implementation → review, so agents do not silently skip requirements or acceptance criteria |
145
+ | **One-Click Setup** | Recreate the same opinionated workflow on a new machine or project with `vvoc install` / `vvoc sync` |
146
+ | **CLI Tooling** | Operate and diagnose the setup from one CLI: install, sync, launch, status, doctor, roles, presets, plugin toggles, completion, and upgrade |
147
+ | **Long-Run Safety** | Guardian keeps safe long/AFK runs moving by auto-approving routine low-risk permissions, while risky actions stay in OpenCode's manual approval flow; secrets redaction reduces accidental leakage |
148
+ | **Model Roles** | Put roles like `vv-role:smart` or `vv-role:fast` in shared agents and skills instead of hardcoded model IDs, then choose provider/model mappings per environment |
149
+ | **Workflow Tracking** | Replace free-form multi-agent chaos with explicit work items, bounded review rounds, reviewer result collection, and hard stops when more context is needed |
131
150
 
132
151
  ---
133
152
 
134
153
  ## The Six Plugins
135
154
 
136
- | Plugin | What it does |
155
+ | Plugin | What it helps you do |
137
156
  |---|---|
138
- | **WorkflowPlugin** | Tracked orchestration around `task` for subagents; registers `work_item_open/list/close` tools with explicit `mode` (`implementation` or `review_only`), `requiredReviewers` (`spec`, `code`), collect-all reviewer rounds, state-machine enforcement, and implementation retry round-limit gating |
139
- | **ModelRolesPlugin** | Resolves `vv-role:*` references in OpenCode config at startup; translates `:variant` suffixes into native model+variant fields |
140
- | **GuardianPlugin** | Reviews OpenCode permission requests with a constrained guardian agent and safe-deny defaults; configurable model, timeout, risk threshold |
141
- | **HashlineEditPlugin** | Replaces OpenCode's `edit` with hash-anchored variant; rewrites `read` output to `line#hash` format; rejects stale snapshots to prevent drift bugs |
142
- | **SystemContextInjectionPlugin** | Injects reusable system guidance into primary sessions without polluting subagent prompts; encourages proactive `explore` usage; registers vvoc skill directory for OpenCode skill discovery |
143
- | **SecretsRedactionPlugin** | Redacts secrets (tokens, keys, emails, UUIDs, IPs) before LLM requests; restores placeholders afterward; configurable patterns |
157
+ | **WorkflowPlugin** | Keep multi-agent work structured with explicit work items, bounded implementation/review loops, reviewer result collection, and safe stops when more context is needed. |
158
+ | **ModelRolesPlugin** | Use semantic model roles instead of hardcoded model IDs in OpenCode agents, subagents, and command configs — e.g. `vv-role:smart`, `vv-role:fast` — then map those roles per machine or project. |
159
+ | **GuardianPlugin** | Keep long or AFK agent runs moving by auto-approving routine low-risk permission requests. If something looks risky, Guardian does not auto-approve it and leaves the decision to OpenCode's normal manual approval flow. |
160
+ | **HashlineEditPlugin** | Make agent edits safer by tying changes to fresh `read` output, reducing wrong-line and stale-context edits. |
161
+ | **SystemContextInjectionPlugin** | Give primary agents the vvoc workflow rules and skill discovery automatically, while keeping subagents focused and avoiding prompt pollution. |
162
+ | **SecretsRedactionPlugin** | Reduce accidental secret leakage by redacting tokens, keys, emails, and other sensitive values before messages are sent to the model. |
144
163
 
145
164
  Workflow work items are opened with explicit intent. For implementation loops, controllers use:
146
165
 
@@ -203,6 +222,7 @@ vvoc preset vv-zai
203
222
  vvoc preset vv-deepseek
204
223
  vvoc preset vv-minimax
205
224
  vvoc preset vv-osovv
225
+ vvoc preset vv-osovv-cheap
206
226
  ```
207
227
 
208
228
  Built-in role IDs: `default`, `smart`, `fast`, `vision` + any custom lowercase-hyphenated IDs.
@@ -227,7 +247,7 @@ OpenCode config → ./.opencode/opencode.json(c)
227
247
  vvoc config → ./.vvoc/vvoc.json
228
248
  Managed agent prompts → ./.vvoc/agents/*.md
229
249
  Managed skills → ./.vvoc/skills/*/SKILL.md
230
- Spec package directory → ./.vvoc/specs/<id>/
250
+ Spec package directory → ./.vvoc/specs/YYYY-MM-DD-<slug>/
231
251
  spec.xml # normative spec document (required)
232
252
  design-context.xml # curated design memory (optional)
233
253
  plan.xml # implementation plan (created by vv-plan)
@@ -243,9 +263,9 @@ Managed agent prompts → $XDG_CONFIG_HOME/vvoc/agents/*.md (global)
243
263
  ./.vvoc/agents/*.md (project)
244
264
  Managed skills → $XDG_CONFIG_HOME/vvoc/skills/*/SKILL.md (global)
245
265
  ./.vvoc/skills/*/SKILL.md (project)
246
- Spec documents → ./.vvoc/specs/<id>/spec.xml
247
- Optional design context → ./.vvoc/specs/<id>/design-context.xml
248
- Implementation plans → ./.vvoc/specs/<id>/plan.xml
266
+ Spec documents → ./.vvoc/specs/YYYY-MM-DD-<slug>/spec.xml
267
+ Optional design context → ./.vvoc/specs/YYYY-MM-DD-<slug>/design-context.xml
268
+ Implementation plans → ./.vvoc/specs/YYYY-MM-DD-<slug>/plan.xml
249
269
  Persisted data → $XDG_DATA_HOME/vvoc/
250
270
  Repository memory → ./.vvoc/lessons/*.xml (lazy vv-reflect fallback)
251
271
  ./.vvoc/runbooks/*.xml (lazy vv-reflect fallback)
@@ -276,15 +296,15 @@ vvoc launch --scope project -- run "hello"
276
296
 
277
297
  All prompt files are scaffolded by `vvoc install` / `vvoc sync`:
278
298
 
279
- | Agent | Role |
299
+ | Agent | When it helps |
280
300
  |---|---|
281
- | `vv-controller` | Default primary agent — routes work to the right subagent |
282
- | `enhancer` | Prompt enhancement |
283
- | `vv-implementer` | Focused implementation with verification |
284
- | `vv-spec-reviewer` | Checks implementation against spec |
285
- | `vv-code-reviewer` | Engineering review for bugs and maintainability |
286
- | `investigator` | Root-cause analysis for unclear bugs |
287
- | `guardian` | Permission request review (plugin runtime) |
301
+ | `vv-controller` | Default primary agent that routes small changes, investigations, reviews, and larger feature work through the right workflow |
302
+ | `enhancer` | Improves rough requests before execution when a clearer prompt would help |
303
+ | `vv-implementer` | Applies a focused approved change and verifies it before reporting completion |
304
+ | `vv-spec-reviewer` | Checks whether implementation matches the requested spec and acceptance criteria |
305
+ | `vv-code-reviewer` | Looks for bugs, regressions, maintainability risks, and missing tests |
306
+ | `investigator` | Finds the root cause first when behavior is unclear or a failure needs diagnosis |
307
+ | `guardian` | Supports GuardianPlugin by auto-approving routine low-risk permission requests and leaving risky ones for manual approval |
288
308
 
289
309
  ---
290
310
 
@@ -292,13 +312,15 @@ All prompt files are scaffolded by `vvoc install` / `vvoc sync`:
292
312
 
293
313
  Five workflow skills are scaffolded alongside agents:
294
314
 
295
- | Skill | Trigger | Output | Grep-able |
296
- |---|---|---|---|
297
- | `vv-spec` | Creative/feature request, no spec exists | `.vvoc/specs/<id>/spec.xml` + optional `design-context.xml` | `<goal>`, `<architecture>`, `<component>` |
298
- | `vv-plan` | Approved spec exists | `.vvoc/specs/<id>/plan.xml` | `<id>T-`, `<criterion>`, `<task_id>`, `/**` JSDoc |
299
- | `vv-execute` | Approved plan exists | Applies and archives spec/plan artifacts | `<status>`, `<task>`, `<acceptance>` |
300
- | `vv-review` | Review request | Findings report | — |
301
- | `vv-reflect` | End of a long development, debugging, bugfix, ops, or investigation session | Existing repo docs or `.vvoc/lessons/*.xml` / `.vvoc/runbooks/*.xml` | XML fallback indexes and entry tags |
315
+ | Skill | When to use it | What it gives you |
316
+ |---|---|---|
317
+ | `vv-spec` | You have a feature or creative request and no agreed contract yet | A guided interview, recommended options, and a saved spec in `.vvoc/specs/YYYY-MM-DD-<slug>/spec.xml` |
318
+ | `vv-plan` | A spec is approved and ready to implement | A task-level implementation plan with file targets, contracts, dependencies, and acceptance criteria |
319
+ | `vv-execute` | A plan is approved and you want it applied step by step | Ordered execution with verification and applied spec/plan archival |
320
+ | `vv-review` | You want findings, not fixes | A review-only workflow that reports spec/code issues and stops before implementation |
321
+ | `vv-reflect` | A long development, debugging, ops, or investigation session produced reusable knowledge | Durable notes in existing docs or `.vvoc/lessons` / `.vvoc/runbooks` for future agents |
322
+
323
+ Spec and plan artifacts stay XML so requirements, tasks, acceptance criteria, and dependencies remain easy to grep and review.
302
324
 
303
325
  `vv-reflect` creates `.vvoc/lessons` and `.vvoc/runbooks` lazily only after approved fallback writes. It prefers an existing repository documentation convention when there is a high-confidence match.
304
326
 
package/dist/lib/vvoc-preset-registry.d.ts CHANGED
@@ -49,7 +49,17 @@ export declare const BUILTIN_VVOC_PRESET_REGISTRY: {
49
49
  readonly reviewer: "zai-coding-plan/glm-5.1";
50
50
  };
51
51
  };
52
+ readonly "vv-osovv-cheap": {
53
+ readonly description: "Cheap osovv role assignments (deepseek + stepfun + minimax + zai).";
54
+ readonly agents: {
55
+ readonly default: "deepseek/deepseek-v4-flash";
56
+ readonly fast: "stepfun/step-3.7-flash";
57
+ readonly smart: "zai-coding-plan/glm-5.1";
58
+ readonly vision: "minimax-coding-plan/MiniMax-M2.7";
59
+ readonly reviewer: "deepseek/deepseek-v4-pro";
60
+ };
61
+ };
52
62
  };
53
63
  export type BuiltInVvocPresetName = keyof typeof BUILTIN_VVOC_PRESET_REGISTRY;
54
- export declare const BUILTIN_VVOC_PRESET_NAMES: readonly ("vv-openai" | "vv-zai" | "vv-minimax" | "vv-deepseek" | "vv-osovv")[];
64
+ export declare const BUILTIN_VVOC_PRESET_NAMES: readonly ("vv-openai" | "vv-zai" | "vv-minimax" | "vv-deepseek" | "vv-osovv" | "vv-osovv-cheap")[];
55
65
  export declare function isBuiltinVvocPresetName(name: string): name is BuiltInVvocPresetName;
package/dist/lib/vvoc-preset-registry.js CHANGED
@@ -70,6 +70,16 @@ export const BUILTIN_VVOC_PRESET_REGISTRY = {
70
70
  reviewer: "zai-coding-plan/glm-5.1",
71
71
  },
72
72
  },
73
+ "vv-osovv-cheap": {
74
+ description: "Cheap osovv role assignments (deepseek + stepfun + minimax + zai).",
75
+ agents: {
76
+ default: "deepseek/deepseek-v4-flash",
77
+ fast: "stepfun/step-3.7-flash",
78
+ smart: "zai-coding-plan/glm-5.1",
79
+ vision: "minimax-coding-plan/MiniMax-M2.7",
80
+ reviewer: "deepseek/deepseek-v4-pro",
81
+ },
82
+ },
73
83
  };
74
84
  export const BUILTIN_VVOC_PRESET_NAMES = Object.freeze(Object.keys(BUILTIN_VVOC_PRESET_REGISTRY));
75
85
  // START_CONTRACT: isBuiltinVvocPresetName
package/dist/lib/vvoc-preset-registry.js.map CHANGED
@@ -1 +1 @@
1
- {"version":3,"file":"vvoc-preset-registry.js","sourceRoot":"","sources":["../../src/lib/vvoc-preset-registry.ts"],"names":[],"mappings":"AAAA,wCAAwC;AACxC,iBAAiB;AACjB,wBAAwB;AACxB,wGAAwG;AACxG,kGAAkG;AAClG,oBAAoB;AACpB,kFAAkF;AAClF,kBAAkB;AAClB,sBAAsB;AACtB,sBAAsB;AACtB,EAAE;AACF,mBAAmB;AACnB,uGAAuG;AACvG,yGAAyG;AACzG,oEAAoE;AACpE,sFAAsF;AACtF,iBAAiB;AACjB,EAAE;AACF,uBAAuB;AACvB,iIAAiI;AACjI,qBAAqB;AAOrB,MAAM,CAAC,MAAM,4BAA4B,GAAG;IAC1C,WAAW,EAAE;QACX,WAAW,EAAE,0DAA0D;QACvE,MAAM,EAAE;YACN,OAAO,EAAE,gBAAgB;YACzB,KAAK,EAAE,yBAAyB;YAChC,IAAI,EAAE,qBAAqB;YAC3B,MAAM,EAAE,gBAAgB;YACxB,QAAQ,EAAE,gBAAgB;SAC3B;KACF;IACD,QAAQ,EAAE;QACR,WAAW,EAAE,uDAAuD;QACpE,MAAM,EAAE;YACN,OAAO,EAAE,6BAA6B;YACtC,KAAK,EAAE,yBAAyB;YAChC,IAAI,EAAE,8BAA8B;YACpC,MAAM,EAAE,0BAA0B;YAClC,QAAQ,EAAE,yBAAyB;SACpC;KACF;IACD,YAAY,EAAE;QACZ,WAAW,EAAE,2DAA2D;QACxE,MAAM,EAAE;YACN,OAAO,EAAE,kCAAkC;YAC3C,KAAK,EAAE,kCAAkC;YACzC,IAAI,EAAE,kCAAkC;YACxC,MAAM,EAAE,kCAAkC;YAC1C,QAAQ,EAAE,kCAAkC;SAC7C;KACF;IACD,aAAa,EAAE;QACb,WAAW,EAAE,4DAA4D;QACzE,MAAM,EAAE;YACN,OAAO,EAAE,4BAA4B;YACrC,KAAK,EAAE,0BAA0B;YACjC,IAAI,EAAE,4BAA4B;YAClC,MAAM,EAAE,0BAA0B;YAClC,QAAQ,EAAE,0BAA0B;SACrC;KACF;IACD,UAAU,EAAE;QACV,WAAW,EAAE,6EAA6E;QAC1F,MAAM,EAAE;YACN,OAAO,EAAE,4BAA4B;YACrC,IAAI,EAAE,wBAAwB;YAC9B,KAAK,EAAE,yBAAyB;YAChC,MAAM,EAAE,kCAAkC;YAC1C,QAAQ,EAAE,yBAAyB;SACpC;KACF;CAC6D,CAAC;AAIjE,MAAM,CAAC,MAAM,yBAAyB,GAAG,MAAM,CAAC,MAAM,CACpD,MAAM,CAAC,IAAI,CAAC,4BAA4B,CAA4B,CACrE,CAAC;AAEF,0CAA0C;AAC1C,0FAA0F;AAC1F,sDAAsD;AACtD,0FAA0F;AAC1F,uBAAuB;AACvB,gDAAgD;AAChD,wCAAwC;AACxC,MAAM,UAAU,uBAAuB,CAAC,IAAY;IAClD,OAAO,MAAM,CAAC,MAAM,CAAC,4BAA4B,EAAE,IAAI,CAAC,CAAC;AAC3D,CAAC"}
1
+ {"version":3,"file":"vvoc-preset-registry.js","sourceRoot":"","sources":["../../src/lib/vvoc-preset-registry.ts"],"names":[],"mappings":"AAAA,wCAAwC;AACxC,iBAAiB;AACjB,wBAAwB;AACxB,wGAAwG;AACxG,kGAAkG;AAClG,oBAAoB;AACpB,kFAAkF;AAClF,kBAAkB;AAClB,sBAAsB;AACtB,sBAAsB;AACtB,EAAE;AACF,mBAAmB;AACnB,uGAAuG;AACvG,yGAAyG;AACzG,oEAAoE;AACpE,sFAAsF;AACtF,iBAAiB;AACjB,EAAE;AACF,uBAAuB;AACvB,iIAAiI;AACjI,qBAAqB;AAOrB,MAAM,CAAC,MAAM,4BAA4B,GAAG;IAC1C,WAAW,EAAE;QACX,WAAW,EAAE,0DAA0D;QACvE,MAAM,EAAE;YACN,OAAO,EAAE,gBAAgB;YACzB,KAAK,EAAE,yBAAyB;YAChC,IAAI,EAAE,qBAAqB;YAC3B,MAAM,EAAE,gBAAgB;YACxB,QAAQ,EAAE,gBAAgB;SAC3B;KACF;IACD,QAAQ,EAAE;QACR,WAAW,EAAE,uDAAuD;QACpE,MAAM,EAAE;YACN,OAAO,EAAE,6BAA6B;YACtC,KAAK,EAAE,yBAAyB;YAChC,IAAI,EAAE,8BAA8B;YACpC,MAAM,EAAE,0BAA0B;YAClC,QAAQ,EAAE,yBAAyB;SACpC;KACF;IACD,YAAY,EAAE;QACZ,WAAW,EAAE,2DAA2D;QACxE,MAAM,EAAE;YACN,OAAO,EAAE,kCAAkC;YAC3C,KAAK,EAAE,kCAAkC;YACzC,IAAI,EAAE,kCAAkC;YACxC,MAAM,EAAE,kCAAkC;YAC1C,QAAQ,EAAE,kCAAkC;SAC7C;KACF;IACD,aAAa,EAAE;QACb,WAAW,EAAE,4DAA4D;QACzE,MAAM,EAAE;YACN,OAAO,EAAE,4BAA4B;YACrC,KAAK,EAAE,0BAA0B;YACjC,IAAI,EAAE,4BAA4B;YAClC,MAAM,EAAE,0BAA0B;YAClC,QAAQ,EAAE,0BAA0B;SACrC;KACF;IACD,UAAU,EAAE;QACV,WAAW,EAAE,6EAA6E;QAC1F,MAAM,EAAE;YACN,OAAO,EAAE,4BAA4B;YACrC,IAAI,EAAE,wBAAwB;YAC9B,KAAK,EAAE,yBAAyB;YAChC,MAAM,EAAE,kCAAkC;YAC1C,QAAQ,EAAE,yBAAyB;SACpC;KACF;IACD,gBAAgB,EAAE;QAChB,WAAW,EAAE,oEAAoE;QACjF,MAAM,EAAE;YACN,OAAO,EAAE,4BAA4B;YACrC,IAAI,EAAE,wBAAwB;YAC9B,KAAK,EAAE,yBAAyB;YAChC,MAAM,EAAE,kCAAkC;YAC1C,QAAQ,EAAE,0BAA0B;SACrC;KACF;CAC6D,CAAC;AAIjE,MAAM,CAAC,MAAM,yBAAyB,GAAG,MAAM,CAAC,MAAM,CACpD,MAAM,CAAC,IAAI,CAAC,4BAA4B,CAA4B,CACrE,CAAC;AAEF,0CAA0C;AAC1C,0FAA0F;AAC1F,sDAAsD;AACtD,0FAA0F;AAC1F,uBAAuB;AACvB,gDAAgD;AAChD,wCAAwC;AACxC,MAAM,UAAU,uBAAuB,CAAC,IAAY;IAClD,OAAO,MAAM,CAAC,MAAM,CAAC,4BAA4B,EAAE,IAAI,CAAC,CAAC;AAC3D,CAAC"}
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@osovv/vv-opencode",
3
- "version": "0.35.28",
4
- "description": "Portable OpenCode workflow toolkit — 6 plugins, managed agents & skills, a spec-to-code pipeline, security, and the vvoc CLI.",
3
+ "version": "0.35.30",
4
+ "description": "A curated, opinionated set of OpenCode plugins for spec-first, review-driven, safer agentic development.",
5
5
  "type": "module",
6
6
  "main": "./dist/index.js",
7
7
  "types": "./dist/index.d.ts",
package/schemas/vvoc/v3.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "$schema": "https://json-schema.org/draft/2020-12/schema",
3
- "$id": "https://cdn.jsdelivr.net/npm/@osovv/vv-opencode@0.35.28/schemas/vvoc/v3.json",
3
+ "$id": "https://cdn.jsdelivr.net/npm/@osovv/vv-opencode@0.35.30/schemas/vvoc/v3.json",
4
4
  "title": "vvoc config",
5
5
  "description": "Canonical vvoc configuration document.",
6
6
  "type": "object",
package/templates/agents/vv-controller.md CHANGED
@@ -127,7 +127,7 @@ Execution order for implementation mode: 1. `vv-implementer` 2. launch all requi
127
127
  </large_feature_protocol>
128
128
 
129
129
  <plan_artifacts>
130
- - **vv-plan implementation plans** live in spec packages. The canonical layout is: `.vvoc/specs/<id>/{spec.xml, design-context.xml optional, plan.xml}`.
130
+ - **vv-plan implementation plans** live in spec packages. The canonical layout is: `.vvoc/specs/YYYY-MM-DD-<slug>/{spec.xml, design-context.xml optional, plan.xml}`.
131
131
  - **spec.xml** is normative — the single source of truth for requirements and design decisions.
132
132
  - **design-context.xml** (optional) is explanatory/non-normative curated design memory for planners and reviewers. It is NOT treated as additional requirements.
133
133
  - **plan.xml** is the vv-plan implementation plan, saved in the same package.
package/templates/skills/vv-plan/SKILL.md CHANGED
@@ -14,7 +14,7 @@ You are the vv-plan skill. Your job is to take an approved spec and write an imp
14
14
  </language>
15
15
 
16
16
  <prerequisites>
17
- <rule>An approved spec MUST exist at .vvoc/specs/&lt;id&gt;/spec.xml before planning begins. The spec package directory &lt;id&gt; derives from the feature name used during vv-spec.</rule>
17
+ <rule>An approved spec MUST exist at .vvoc/specs/&lt;id&gt;/spec.xml before planning begins. For newly created specs, vv-spec derives &lt;id&gt; as a date-prefixed package id in the form YYYY-MM-DD-&lt;slug&gt; from the feature name.</rule>
18
18
  <rule>Read the spec file in full.</rule>
19
19
  <rule>Check whether a sibling design-context.xml exists at .vvoc/specs/&lt;id&gt;/design-context.xml. If it exists, read it as explanatory context only. design-context.xml does NOT override or expand spec.xml — spec.xml remains normative and wins on conflicts.</rule>
20
20
  <rule>The spec's top-level &lt;status&gt; MUST be approved. If the status is draft, missing, applied, or any other value, stop and tell the user the spec must be explicitly approved before planning.</rule>
package/templates/skills/vv-spec/SKILL.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: vv-spec
3
- description: Use BEFORE any implementation or planning — interviews the user one question at a time, proposes approaches, presents a design, writes a spec document to .vvoc/specs/<id>/spec.xml, and optionally creates a design-context.xml companion for complex sessions
3
+ description: Use BEFORE any implementation or planning — interviews the user one question at a time, proposes approaches, presents a design, writes a spec document to .vvoc/specs/YYYY-MM-DD-<slug>/spec.xml, and optionally creates a design-context.xml companion for complex sessions
4
4
  ---
5
5
 
6
6
  <skill>
@@ -51,12 +51,12 @@ UX cues (roadmap, progress markers, depth estimates, checkpoints) are TRANSPAREN
51
51
  <rule>When first saving the spec, set &lt;status&gt;draft&lt;/status&gt;. Only change it to approved after the user explicitly approves the final spec. Never set applied yourself; applied is reserved for vv-execute after the approved plan has been fully executed.</rule>
52
52
  <location>Canonical layout — all artifacts for one feature live in a single spec package directory:</location>
53
53
  <layout>
54
- .vvoc/specs/&lt;id&gt;/
54
+ .vvoc/specs/YYYY-MM-DD-&lt;slug&gt;/
55
55
  spec.xml # normative spec document (required)
56
56
  design-context.xml # curated design memory (optional)
57
57
  plan.xml # implementation plan (created by vv-plan)
58
58
  </layout>
59
- <rule>Save spec.xml to .vvoc/specs/&lt;id&gt;/spec.xml. Derive &lt;id&gt; as a safe slug from the feature name (e.g., cache-store, batch-migration). Ensure the slug: (a) contains only lowercase alphanumeric characters, hyphens, and underscores; (b) does not start or end with a hyphen or underscore. Reject reserved names: draft, archive, template, plan, spec, vvoc, or names that match path-like patterns (contain /, \, .., or match an existing filesystem path separator). If .vvoc/specs/&lt;id&gt;/ already exists, check whether it is a continuation of the same draft session (same spec package from the same feature) — if yes, overwrite; if not, stop and ask the user for a different id or explicit overwrite approval. Do not silently overwrite or merge an unrelated existing package. Do not use date prefixes — the package directory is the organizational unit.</rule>
59
+ <rule>Save spec.xml to .vvoc/specs/&lt;id&gt;/spec.xml, where &lt;id&gt; is a date-prefixed package id in the form YYYY-MM-DD-&lt;slug&gt; (for example, 2026-06-24-cache-store). Derive &lt;slug&gt; as a safe slug from the feature name (e.g., cache-store, batch-migration), then prefix it with the current date at spec creation time in YYYY-MM-DD format. Ensure the slug portion: (a) contains only lowercase alphanumeric characters, hyphens, and underscores; (b) does not start or end with a hyphen or underscore. Reject reserved slug values: draft, archive, template, plan, spec, vvoc, or names that match path-like patterns (contain /, \, .., or match an existing filesystem path separator). If .vvoc/specs/&lt;id&gt;/ already exists, check whether it is a continuation of the same draft session (same spec package from the same feature and date) — if yes, overwrite; if not, stop and ask the user for a different slug or explicit overwrite approval. Do not silently overwrite or merge an unrelated existing package.</rule>
60
60
  <rule>After creating or updating spec.xml, consider whether the session warrants a design-context.xml companion (see design_context section below).</rule>
61
61
  </spec_document_format>
62
62
 
@@ -73,7 +73,7 @@ UX cues (roadmap, progress markers, depth estimates, checkpoints) are TRANSPAREN
73
73
  <trigger>the user explicitly asks to preserve reasoning or design rationale</trigger>
74
74
  <rule>Load the design context template from references/design-context-template.xml. Fill only the sections that are relevant — leave unused sections empty or omit them.</rule>
75
75
  <rule>Do NOT include the full interview transcript, raw conversation dumps, chain-of-thought traces, or repetitive restatements of spec.xml content.</rule>
76
- <rule>Save design-context.xml as a sibling of spec.xml in the same spec package directory: .vvoc/specs/&lt;id&gt;/design-context.xml</rule>
76
+ <rule>Save design-context.xml as a sibling of spec.xml in the same date-prefixed spec package directory: .vvoc/specs/&lt;id&gt;/design-context.xml</rule>
77
77
  </design_context>
78
78
 
79
79
  <self_review>
@@ -98,6 +98,6 @@ UX cues (roadmap, progress markers, depth estimates, checkpoints) are TRANSPAREN
98
98
  </handoff>
99
99
 
100
100
  <task>
101
- Your current task is the ongoing user request. Walk the decision tree relentlessly — one branch at a time. Propose approaches, present a design section by section, get approval at each stage. Load the spec template from references/spec-template.xml and fill every element with confirmed decisions. Save to .vvoc/specs/&lt;id&gt;/spec.xml as XML with document status draft. Optionally create .vvoc/specs/&lt;id&gt;/design-context.xml for complex sessions. After explicit user approval, update the saved spec status to approved. Stop before any implementation or planning.
101
+ Your current task is the ongoing user request. Walk the decision tree relentlessly — one branch at a time. Propose approaches, present a design section by section, get approval at each stage. Load the spec template from references/spec-template.xml and fill every element with confirmed decisions. Save to .vvoc/specs/&lt;id&gt;/spec.xml, where &lt;id&gt; is YYYY-MM-DD-&lt;slug&gt; using the current date at spec creation time, as XML with document status draft. Optionally create .vvoc/specs/&lt;id&gt;/design-context.xml for complex sessions. After explicit user approval, update the saved spec status to approved. Stop before any implementation or planning.
102
102
  </task>
103
103
  </skill>