npm - @osovv/vv-opencode - Versions diffs - 0.35.29 → 0.35.31 - Mend

@osovv/vv-opencode 0.35.29 → 0.35.31

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 (11) hide show

package/CHANGELOG.md +28 -0
package/README.md +19 -12
package/dist/lib/managed-skills.d.ts +1 -1
package/dist/lib/managed-skills.js +4 -2
package/dist/lib/managed-skills.js.map +1 -1
package/package.json +1 -1
package/schemas/vvoc/v3.json +1 -1
package/templates/agents/vv-controller.md +1 -1
package/templates/skills/vv-handoff/SKILL.md +71 -0
package/templates/skills/vv-plan/SKILL.md +1 -1
package/templates/skills/vv-spec/SKILL.md +5 -5

package/CHANGELOG.md CHANGED Viewed

@@ -1,3 +1,31 @@
+## <small>0.35.31 (2026-06-25)</small>
+### Summary
+This release adds the `vv-handoff` managed skill, a lightweight end-of-session tool that writes a project-local XML handoff note from already-visible session context—recording the original request, completed work, current state and decisions, important files, known command results, blockers, and the next safe step—without running shell commands or collecting fresh evidence, and with automatic secret redaction and collision-safe directory naming. The `vv-spec` skill documentation was also clarified to ensure spec package date prefixes remain date-only, excluding any time or timezone components.
+* docs(grace): add vv-handoff skill spec and plan ([490c96e](https://github.com/osovv/vv-opencode/commit/490c96e))
+* docs(vv-spec): clarify date-only spec package prefix ([cba76f5](https://github.com/osovv/vv-opencode/commit/cba76f5))
+* feat(skills): add vv-handoff managed skill ([a386c5a](https://github.com/osovv/vv-opencode/commit/a386c5a))
+## <small>0.35.30 (2026-06-24)</small>
+### Summary
+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.
+* feat(vv-spec): date-prefix spec packages ([0dba659](https://github.com/osovv/vv-opencode/commit/0dba659))
+* docs: drop migration report artifact ([327812d](https://github.com/osovv/vv-opencode/commit/327812d))
+* docs: finalize GRACE migration cleanup ([496236f](https://github.com/osovv/vv-opencode/commit/496236f))
+* docs: migrate project to GRACE 4 ([ba3e162](https://github.com/osovv/vv-opencode/commit/ba3e162))
+* docs: refine GRACE context requirements ([73245b1](https://github.com/osovv/vv-opencode/commit/73245b1))
+* docs: refine GRACE deployment context ([cd2da0f](https://github.com/osovv/vv-opencode/commit/cd2da0f))
+* docs: refine GRACE principles context ([ad1b050](https://github.com/osovv/vv-opencode/commit/ad1b050))
+* docs: refine GRACE technology context ([eeff4d2](https://github.com/osovv/vv-opencode/commit/eeff4d2))
+* docs: refine GRACE UX guidelines ([09d075a](https://github.com/osovv/vv-opencode/commit/09d075a))
+* docs: remove legacy GRACE 3 artifacts ([c9b910d](https://github.com/osovv/vv-opencode/commit/c9b910d))
+* docs: remove stale GRACE migration references ([6ad640a](https://github.com/osovv/vv-opencode/commit/6ad640a))
 ## <small>0.35.29 (2026-06-22)</small>
 ### Summary

package/README.md CHANGED Viewed

@@ -20,7 +20,7 @@ bun add -g @osovv/vv-opencode
 vvoc install
 ```
-That's it. `vvoc install` pins the package, scaffolds managed agents and skills, writes canonical config, and sets `vv-controller` as your default OpenCode agent with auto-triggered spec, planning, review, and reflection skills.
+That's it. `vvoc install` pins the package, scaffolds managed agents and skills, writes canonical config, and sets `vv-controller` as your default OpenCode agent with auto-triggered spec, planning, review, reflection, and handoff skills.
 To scope everything to the current project instead of the global OpenCode config:
@@ -44,12 +44,12 @@ Request / idea
    ↓
 vv-spec
    asks clarifying questions
-   writes .vvoc/specs/<id>/spec.xml
+   writes .vvoc/specs/YYYY-MM-DD-<slug>/spec.xml
    waits for spec approval
    ↓
 vv-plan
    reads the approved spec
-   writes .vvoc/specs/<id>/plan.xml
+   writes .vvoc/specs/YYYY-MM-DD-<slug>/plan.xml
    defines tasks, contracts, dependencies, and acceptance criteria
    waits for plan approval
    ↓
@@ -84,13 +84,15 @@ verification
 All artifacts for one feature live together:
 ```text
-.vvoc/specs/<id>/
+.vvoc/specs/YYYY-MM-DD-<slug>/
   spec.xml            # what should be built and why
   design-context.xml  # optional design memory
   plan.xml            # how to implement and verify it
 ```
-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>/`.
+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. The prefix is date-only; it must not include hours, minutes, seconds, timezone, or a full ISO timestamp.
+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>/`.
 ### XML grep
@@ -113,7 +115,7 @@ grep '/\*\*' .vvoc/specs/*/plan.xml
 grep '<name>' .vvoc/specs/*/plan.xml
 ```
-Managed skills are installed by `vvoc`. `vv-controller` explicitly routes `vv-spec`, `vv-plan`, and `vv-review`; `vv-execute` and `vv-reflect` are available as managed skills for plan execution and durable session memory.
+Managed skills are installed by `vvoc`. `vv-controller` explicitly routes `vv-spec`, `vv-plan`, and `vv-review`; `vv-execute`, `vv-reflect`, and `vv-handoff` are available as managed skills for plan execution, durable repository memory, and end-of-session handoff notes.
 ---
@@ -245,10 +247,11 @@ OpenCode config          → ./.opencode/opencode.json(c)
 vvoc config              → ./.vvoc/vvoc.json
 Managed agent prompts    → ./.vvoc/agents/*.md
 Managed skills           → ./.vvoc/skills/*/SKILL.md
-Spec package directory   → ./.vvoc/specs/<id>/
+Spec package directory   → ./.vvoc/specs/YYYY-MM-DD-<slug>/
   spec.xml              # normative spec document (required)
   design-context.xml    # curated design memory (optional)
   plan.xml              # implementation plan (created by vv-plan)
+Handoff notes            → ./.vvoc/handoff/YYYY-MM-DD-<session-slug>/handoff.xml
 ```
@@ -261,12 +264,13 @@ Managed agent prompts    → $XDG_CONFIG_HOME/vvoc/agents/*.md  (global)
                            ./.vvoc/agents/*.md                 (project)
 Managed skills           → $XDG_CONFIG_HOME/vvoc/skills/*/SKILL.md  (global)
                            ./.vvoc/skills/*/SKILL.md               (project)
-Spec documents           → ./.vvoc/specs/<id>/spec.xml
-Optional design context  → ./.vvoc/specs/<id>/design-context.xml
-Implementation plans     → ./.vvoc/specs/<id>/plan.xml
+Spec documents           → ./.vvoc/specs/YYYY-MM-DD-<slug>/spec.xml
+Optional design context  → ./.vvoc/specs/YYYY-MM-DD-<slug>/design-context.xml
+Implementation plans     → ./.vvoc/specs/YYYY-MM-DD-<slug>/plan.xml
 Persisted data           → $XDG_DATA_HOME/vvoc/
 Repository memory       → ./.vvoc/lessons/*.xml              (lazy vv-reflect fallback)
                            ./.vvoc/runbooks/*.xml             (lazy vv-reflect fallback)
+Session handoff notes   → ./.vvoc/handoff/YYYY-MM-DD-<session-slug>/handoff.xml
 ```
 Schema is versioned and published with the package — source of truth at `schemas/vvoc/v3.json`. The current config contract is strict: `vvoc.json` must be canonical version 3 and include required sections such as `plugins`. Existing v1/v2/pre-role, incomplete, malformed, or otherwise invalid config files fail instead of being migrated or repaired. `vvoc install` and `vvoc sync` may create a fresh canonical config when no config exists, but they refuse to rewrite an invalid existing `vvoc.json`; fix the file manually and rerun `vvoc sync`.
@@ -308,20 +312,23 @@ All prompt files are scaffolded by `vvoc install` / `vvoc sync`:
 ## Managed Skills
-Five workflow skills are scaffolded alongside agents:
+Six workflow skills are scaffolded alongside agents:
 | Skill | When to use it | What it gives you |
 |---|---|---|
-| `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/<id>/spec.xml` |
+| `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` |
 | `vv-plan` | A spec is approved and ready to implement | A task-level implementation plan with file targets, contracts, dependencies, and acceptance criteria |
 | `vv-execute` | A plan is approved and you want it applied step by step | Ordered execution with verification and applied spec/plan archival |
 | `vv-review` | You want findings, not fixes | A review-only workflow that reports spec/code issues and stops before implementation |
 | `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 |
+| `vv-handoff` | You are ending a session and want the visible context preserved for a future session | A redacted XML note at `.vvoc/handoff/YYYY-MM-DD-<session-slug>/handoff.xml`, without running new checks or collecting fresh context |
 Spec and plan artifacts stay XML so requirements, tasks, acceptance criteria, and dependencies remain easy to grep and review.
 `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.
+`vv-handoff` writes only the project-local XML handoff artifact from context already visible in the session. It records missing git, diff, or verification evidence as not collected in the current session instead of running commands.
 Skills are loaded by OpenCode at session start through `config.skills.paths` (registered by the SystemContextInjectionPlugin). The `vv-controller` agent's `<skill_trigger_rule>` ensures they are invoked automatically when the user's request matches their trigger conditions.
 ---

package/dist/lib/managed-skills.d.ts CHANGED Viewed

@@ -1,4 +1,4 @@
-export declare const MANAGED_SKILL_NAMES: readonly ["vv-spec", "vv-plan", "vv-review", "vv-execute", "vv-reflect"];
+export declare const MANAGED_SKILL_NAMES: readonly ["vv-spec", "vv-plan", "vv-review", "vv-execute", "vv-reflect", "vv-handoff"];
 export type ManagedSkillName = (typeof MANAGED_SKILL_NAMES)[number];
 export declare function getManagedSkillFilePath(skillsDirPath: string, name: ManagedSkillName): string;
 export declare function loadManagedSkillTemplate(name: ManagedSkillName): Promise<string>;

package/dist/lib/managed-skills.js CHANGED Viewed

@@ -1,5 +1,5 @@
 // FILE: src/lib/managed-skills.ts
-// VERSION: 0.5.2
+// VERSION: 0.5.3
 // START_MODULE_CONTRACT
 //   PURPOSE: Describe vvoc-managed OpenCode skills and load them from bundled templates or scoped vvoc config roots.
 //   SCOPE: Managed skill names, skill file path resolution, bundled template loading, reference file discovery, and project/global skill lookup.
@@ -10,7 +10,7 @@
 // END_MODULE_CONTRACT
 //
 // START_MODULE_MAP
-//   MANAGED_SKILL_NAMES - Canonical vvoc-managed skill names, including vv-reflect.
+//   MANAGED_SKILL_NAMES - Canonical vvoc-managed skill names, including vv-reflect and vv-handoff.
 //   ManagedSkillName - Type for vvoc-managed skill names.
 //   getManagedSkillFilePath - Resolves the skill file path inside a vvoc skills directory.
 //   loadManagedSkillTemplate - Loads the bundled skill template for a managed skill.
@@ -20,6 +20,7 @@
 // END_MODULE_MAP
 //
 // START_CHANGE_SUMMARY
+//   LAST_CHANGE: [v0.5.3 - Added vv-handoff to the canonical managed skill set.]
 //   LAST_CHANGE: [v0.5.2 - Added vv-reflect to the canonical managed skill set.]
 //   LAST_CHANGE: [v0.5.1 - Added loadManagedSkillReference and listManagedSkillReferenceNames for copying reference files alongside skill templates.]
 //   LAST_CHANGE: [v0.5.0 - Initial module for managed skill file resolution and template loading.]
@@ -33,6 +34,7 @@ export const MANAGED_SKILL_NAMES = [
     "vv-review",
     "vv-execute",
     "vv-reflect",
+    "vv-handoff",
 ];
 export function getManagedSkillFilePath(skillsDirPath, name) {
     return join(skillsDirPath, name, "SKILL.md");

package/dist/lib/managed-skills.js.map CHANGED Viewed

	@@ -1 +1 @@
1	- {"version":3,"file":"managed-skills.js","sourceRoot":"","sources":["../../src/lib/managed-skills.ts"],"names":[],"mappings":"AAAA,kCAAkC;AAClC,iBAAiB;AACjB,wBAAwB;AACxB,qHAAqH;AACrH,iJAAiJ;AACjJ,4EAA4E;AAC5E,kCAAkC;AAClC,kBAAkB;AAClB,sBAAsB;AACtB,sBAAsB;AACtB,EAAE;AACF,mBAAmB;AACnB,~~oFAAoF~~;~~AACpF~~,0DAA0D;AAC1D,2FAA2F;AAC3F,qFAAqF;AACrF,oFAAoF;AACpF,qFAAqF;AACrF,kHAAkH;AAClH,iBAAiB;AACjB,EAAE;AACF,uBAAuB;AACvB,iFAAiF;AACjF,sJAAsJ;AACtJ,mGAAmG;AACnG,qBAAqB;AACrB,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,MAAM,kBAAkB,CAAC;AACrD,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,gBAAgB,EAAE,iBAAiB,EAAE,gBAAgB,EAAE,MAAM,iBAAiB,CAAC;AAExF,MAAM,CAAC,MAAM,mBAAmB,GAAG;IACjC,SAAS;IACT,SAAS;IACT,WAAW;IACX,YAAY;IACZ,YAAY;CACJ,CAAC;AAIX,MAAM,UAAU,uBAAuB,CAAC,aAAqB,EAAE,IAAsB;IACnF,OAAO,IAAI,CAAC,aAAa,EAAE,IAAI,EAAE,UAAU,CAAC,CAAC;AAC/C,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,wBAAwB,CAAC,IAAsB;IACnE,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,0BAA0B,IAAI,WAAW,EAAE,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACrF,OAAO,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC,CAAC;AACpC,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,yBAAyB,CAC7C,IAAsB,EACtB,iBAAyB;IAEzB,MAAM,QAAQ,GAAG,IAAI,GAAG,CACtB,0BAA0B,IAAI,eAAe,iBAAiB,EAAE,EAChE,MAAM,CAAC,IAAI,CAAC,GAAG,CAChB,CAAC;IACF,OAAO,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC,CAAC;AACpC,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,8BAA8B,CAAC,IAAsB;IACzE,MAAM,SAAS,GAAG,IAAI,GAAG,CAAC,0BAA0B,IAAI,cAAc,EAAE,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACzF,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,MAAM,OAAO,CAAC,SAAS,CAAC,CAAC;QACzC,OAAO,OAAO,CAAC;IACjB,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,IAAK,KAA+B,CAAC,IAAI,KAAK,QAAQ,EAAE,CAAC;YACvD,OAAO,EAAE,CAAC;QACZ,CAAC;QACD,MAAM,KAAK,CAAC;IACd,CAAC;AACH,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,oBAAoB,CACxC,SAAiB,EACjB,IAAsB;IAEtB,MAAM,cAAc,GAAG;QACrB,uBAAuB,CAAC,gBAAgB,CAAC,iBAAiB,CAAC,SAAS,CAAC,CAAC,EAAE,IAAI,CAAC;QAC7E,uBAAuB,CAAC,gBAAgB,CAAC,gBAAgB,EAAE,CAAC,EAAE,IAAI,CAAC;KACpE,CAAC;IAEF,KAAK,MAAM,aAAa,IAAI,cAAc,EAAE,CAAC;QAC3C,IAAI,CAAC;YACH,OAAO,MAAM,QAAQ,CAAC,aAAa,EAAE,MAAM,CAAC,CAAC;QAC/C,CAAC;QAAC,OAAO,KAAK,EAAE,CAAC;YACf,IAAK,KAA+B,CAAC,IAAI,KAAK,QAAQ,EAAE,CAAC;gBACvD,SAAS;YACX,CAAC;YACD,MAAM,KAAK,CAAC;QACd,CAAC;IACH,CAAC;IAED,MAAM,IAAI,KAAK,CACb,oCAAoC,IAAI,qDAAqD,cAAc,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CACzH,CAAC;AACJ,CAAC"}
1	+ {"version":3,"file":"managed-skills.js","sourceRoot":"","sources":["../../src/lib/managed-skills.ts"],"names":[],"mappings":"AAAA,kCAAkC;AAClC,iBAAiB;AACjB,wBAAwB;AACxB,qHAAqH;AACrH,iJAAiJ;AACjJ,4EAA4E;AAC5E,kCAAkC;AAClC,kBAAkB;AAClB,sBAAsB;AACtB,sBAAsB;AACtB,EAAE;AACF,mBAAmB;AACnB,mGAAmG;AACnG,0DAA0D;AAC1D,2FAA2F;AAC3F,qFAAqF;AACrF,oFAAoF;AACpF,qFAAqF;AACrF,kHAAkH;AAClH,iBAAiB;AACjB,EAAE;AACF,uBAAuB;AACvB,iFAAiF;AACjF,iFAAiF;AACjF,sJAAsJ;AACtJ,mGAAmG;AACnG,qBAAqB;AACrB,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,MAAM,kBAAkB,CAAC;AACrD,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,gBAAgB,EAAE,iBAAiB,EAAE,gBAAgB,EAAE,MAAM,iBAAiB,CAAC;AAExF,MAAM,CAAC,MAAM,mBAAmB,GAAG;IACjC,SAAS;IACT,SAAS;IACT,WAAW;IACX,YAAY;IACZ,YAAY;IACZ,YAAY;CACJ,CAAC;AAIX,MAAM,UAAU,uBAAuB,CAAC,aAAqB,EAAE,IAAsB;IACnF,OAAO,IAAI,CAAC,aAAa,EAAE,IAAI,EAAE,UAAU,CAAC,CAAC;AAC/C,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,wBAAwB,CAAC,IAAsB;IACnE,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,0BAA0B,IAAI,WAAW,EAAE,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACrF,OAAO,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC,CAAC;AACpC,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,yBAAyB,CAC7C,IAAsB,EACtB,iBAAyB;IAEzB,MAAM,QAAQ,GAAG,IAAI,GAAG,CACtB,0BAA0B,IAAI,eAAe,iBAAiB,EAAE,EAChE,MAAM,CAAC,IAAI,CAAC,GAAG,CAChB,CAAC;IACF,OAAO,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC,CAAC;AACpC,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,8BAA8B,CAAC,IAAsB;IACzE,MAAM,SAAS,GAAG,IAAI,GAAG,CAAC,0BAA0B,IAAI,cAAc,EAAE,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACzF,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,MAAM,OAAO,CAAC,SAAS,CAAC,CAAC;QACzC,OAAO,OAAO,CAAC;IACjB,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,IAAK,KAA+B,CAAC,IAAI,KAAK,QAAQ,EAAE,CAAC;YACvD,OAAO,EAAE,CAAC;QACZ,CAAC;QACD,MAAM,KAAK,CAAC;IACd,CAAC;AACH,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,oBAAoB,CACxC,SAAiB,EACjB,IAAsB;IAEtB,MAAM,cAAc,GAAG;QACrB,uBAAuB,CAAC,gBAAgB,CAAC,iBAAiB,CAAC,SAAS,CAAC,CAAC,EAAE,IAAI,CAAC;QAC7E,uBAAuB,CAAC,gBAAgB,CAAC,gBAAgB,EAAE,CAAC,EAAE,IAAI,CAAC;KACpE,CAAC;IAEF,KAAK,MAAM,aAAa,IAAI,cAAc,EAAE,CAAC;QAC3C,IAAI,CAAC;YACH,OAAO,MAAM,QAAQ,CAAC,aAAa,EAAE,MAAM,CAAC,CAAC;QAC/C,CAAC;QAAC,OAAO,KAAK,EAAE,CAAC;YACf,IAAK,KAA+B,CAAC,IAAI,KAAK,QAAQ,EAAE,CAAC;gBACvD,SAAS;YACX,CAAC;YACD,MAAM,KAAK,CAAC;QACd,CAAC;IACH,CAAC;IAED,MAAM,IAAI,KAAK,CACb,oCAAoC,IAAI,qDAAqD,cAAc,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CACzH,CAAC;AACJ,CAAC"}

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@osovv/vv-opencode",
-  "version": "0.35.29",
+  "version": "0.35.31",
   "description": "A curated, opinionated set of OpenCode plugins for spec-first, review-driven, safer agentic development.",
   "type": "module",
   "main": "./dist/index.js",

package/schemas/vvoc/v3.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://cdn.jsdelivr.net/npm/@osovv/vv-opencode@0.35.29/schemas/vvoc/v3.json",
+  "$id": "https://cdn.jsdelivr.net/npm/@osovv/vv-opencode@0.35.31/schemas/vvoc/v3.json",
   "title": "vvoc config",
   "description": "Canonical vvoc configuration document.",
   "type": "object",

package/templates/agents/vv-controller.md CHANGED Viewed

@@ -127,7 +127,7 @@ Execution order for implementation mode: 1. `vv-implementer` 2. launch all requi
 </large_feature_protocol>
 <plan_artifacts>
-- **vv-plan implementation plans** live in spec packages. The canonical layout is: `.vvoc/specs/<id>/{spec.xml, design-context.xml optional, plan.xml}`.
+- **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}`.
   - **spec.xml** is normative — the single source of truth for requirements and design decisions.
   - **design-context.xml** (optional) is explanatory/non-normative curated design memory for planners and reviewers. It is NOT treated as additional requirements.
   - **plan.xml** is the vv-plan implementation plan, saved in the same package.

package/templates/skills/vv-handoff/SKILL.md ADDED Viewed

@@ -0,0 +1,71 @@
+---
+name: vv-handoff
+description: Use at the end of a session to write a project-local XML handoff note from already-visible context only.
+---
+<skill>
+<identity>
+You are the vv-handoff skill. Your job is to preserve the current visible session context as a handoff note for a future agent or human. You write one XML file in the current project. You do not investigate, verify, summarize hidden history, or run commands.
+</identity>
+<scope>
+<rule>Use only the current visible chat context and facts already known in this session.</rule>
+<rule>Do not reconstruct hidden, compacted, unavailable, or earlier conversation history.</rule>
+<rule>Do not run shell commands, tests, lint, build, git status, git diff, web searches, repository scans, or any other fresh context collection step.</rule>
+<rule>If git status, git diff, verification, or other evidence was not already collected in the current session, record it as not collected in current session rather than collecting it during handoff.</rule>
+<rule>Do not create a CLI command, plugin, runtime hook, automatic writer, schema validator, or handoff.md artifact.</rule>
+</scope>
+<destination>
+<rule>Write exactly one canonical handoff artifact under the current project: .vvoc/handoff/YYYY-MM-DD-&lt;session-slug&gt;/handoff.xml.</rule>
+<rule>Derive &lt;session-slug&gt; from the main session goal using lowercase words, hyphens, and only URL/path-safe characters.</rule>
+<rule>Use the current local date for YYYY-MM-DD when it is already available in the session environment; otherwise use the date visible in system context.</rule>
+<rule>If the destination directory already exists, choose the first available collision suffix: -2, then -3, and later integers, yielding paths such as .vvoc/handoff/YYYY-MM-DD-&lt;session-slug&gt;-2/.</rule>
+<rule>Filesystem checks and directory/file creation are allowed only to choose and write the destination path. Do not inspect project files for additional context.</rule>
+</destination>
+<redaction>
+<rule>Before writing handoff.xml, redact secrets from the handoff content.</rule>
+<rule>Replace tokens, API keys, passwords, cookies, private URLs, private headers, credentials, private keys, and similar sensitive values with [REDACTED].</rule>
+<rule>If unsure whether a value is sensitive, redact it.</rule>
+</redaction>
+<handoff_xml>
+<rule>The XML does not need a formal schema and must not be schema-validated.</rule>
+<rule>Use clear, grep-friendly element names and concise prose.</rule>
+<rule>Include these required sections:</rule>
+<section>original_request - The user's original goal or request as visible in this session.</section>
+<section>completed_work - Work completed in this session, including files changed when already known.</section>
+<section>current_state_and_decisions - Current state, important decisions, accepted assumptions, selected route, and any pending lifecycle state.</section>
+<section>important_or_changed_files - Important files and changed files already known from the session. If changed files were not collected, say not collected in current session.</section>
+<section>known_commands_and_results - Commands, checks, tests, git status, git diff, and verification results already run in this session. For missing evidence, write not collected in current session.</section>
+<section>blockers_risks_unknowns - Blockers, risks, unknowns, skipped checks, residual uncertainty, and anything a future session must not assume.</section>
+<section>next_safe_step - The single safest next action for the next session.</section>
+</handoff_xml>
+<template>
+<![CDATA[
+<handoff>
+  <original_request></original_request>
+  <completed_work></completed_work>
+  <current_state_and_decisions></current_state_and_decisions>
+  <important_or_changed_files></important_or_changed_files>
+  <known_commands_and_results></known_commands_and_results>
+  <blockers_risks_unknowns></blockers_risks_unknowns>
+  <next_safe_step></next_safe_step>
+</handoff>
+]]>
+</template>
+<workflow>
+<step>Identify the main session goal from the visible context and derive the date-slug directory name.</step>
+<step>Draft handoff.xml using only visible/known context and the required sections.</step>
+<step>Replace every sensitive value with [REDACTED].</step>
+<step>Create the destination directory with collision suffixing if needed, then write handoff.xml.</step>
+<step>Reply with the path written and note that no fresh commands or checks were run.</step>
+</workflow>
+<task>
+Your current task is the ongoing user request. Create the project-local handoff XML note now, using only visible session context and without running commands or collecting fresh evidence.
+</task>
+</skill>

package/templates/skills/vv-plan/SKILL.md CHANGED Viewed

@@ -14,7 +14,7 @@ You are the vv-plan skill. Your job is to take an approved spec and write an imp
 </language>
 <prerequisites>
-<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>
+<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>
 <rule>Read the spec file in full.</rule>
 <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>
 <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 Viewed

@@ -1,6 +1,6 @@
 ---
 name: vv-spec
-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
+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
 ---
 <skill>
@@ -51,12 +51,12 @@ UX cues (roadmap, progress markers, depth estimates, checkpoints) are TRANSPAREN
 <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>
 <location>Canonical layout — all artifacts for one feature live in a single spec package directory:</location>
 <layout>
-.vvoc/specs/&lt;id&gt;/
+.vvoc/specs/YYYY-MM-DD-&lt;slug&gt;/
   spec.xml              # normative spec document (required)
   design-context.xml    # curated design memory (optional)
   plan.xml              # implementation plan (created by vv-plan)
 </layout>
-<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>
+<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. The date prefix is date-only: do not include hours, minutes, seconds, timezone, or a full ISO datetime/timestamp. 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>
 <rule>After creating or updating spec.xml, consider whether the session warrants a design-context.xml companion (see design_context section below).</rule>
 </spec_document_format>
@@ -73,7 +73,7 @@ UX cues (roadmap, progress markers, depth estimates, checkpoints) are TRANSPAREN
 <trigger>the user explicitly asks to preserve reasoning or design rationale</trigger>
 <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>
 <rule>Do NOT include the full interview transcript, raw conversation dumps, chain-of-thought traces, or repetitive restatements of spec.xml content.</rule>
-<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>
+<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>
 </design_context>
 <self_review>
@@ -98,6 +98,6 @@ UX cues (roadmap, progress markers, depth estimates, checkpoints) are TRANSPAREN
 </handoff>
 <task>
-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.
+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; this prefix must be date-only, with no time, timezone, or full timestamp. Save 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.
 </task>
 </skill>