docs: declare 1.0 stability posture

Author: osovv

.grace/context/deployment.xml

@@ -1,6 +1,7 @@
 <GraceDeployment graceVersion="4.0">
   <Applicability>applicable</Applicability>
   <Target>Public npm package @osovv/vv-opencode with Bun CLI binary vvoc and OpenCode plugin exports.</Target>
+  <StabilityPosture>Version 1.0.0 is the daily-driver baseline for the curated vvoc workflow. The release treats setup commands, public package exports, canonical vvoc schema v3, managed skill names, and spec artifact layout as compatibility surfaces unless future release notes explicitly document a breaking change.</StabilityPosture>
   <PackageFiles>
     <File>dist</File>
     <File>schemas</File>

.grace/context/requirements.xml

@@ -15,6 +15,7 @@
     <Goal>Make multi-agent work explicit through work items, tracked subagent headers, reviewer result collection, hard stops, and bounded review rounds.</Goal>
     <Goal>Improve long-run safety with Guardian permission review, secrets redaction, hashline-backed edits, strict config validation, and clear recovery diagnostics.</Goal>
     <Goal>Provide one CLI, vvoc, for setup, sync, launch, status, diagnostics, roles, presets, plugin toggles, completions, and upgrades.</Goal>
+    <Goal>Maintain the 1.0 daily-driver baseline as a practical, curated OpenCode workflow whose setup commands, managed skill trajectory, public package exports, schema v3, and spec artifact layout remain stable compatibility surfaces unless a release explicitly documents a breaking change.</Goal>
   </Goals>
   <UseCases>
     <UC-001>
@@ -182,6 +183,7 @@
     <Constraint>Project-owned specs and plans produced by vvoc skills live under date-prefixed package directories .vvoc/specs/YYYY-MM-DD-&lt;slug&gt;/.</Constraint>
     <Constraint>Hashline-backed editing must fail safely on stale or malformed edit references instead of applying ambiguous line-based changes.</Constraint>
     <Constraint>Package exports are public API and must remain valid unless an explicit breaking change is approved.</Constraint>
+    <Constraint>After the 1.0 stabilization point, user-facing setup flow, managed skill names, canonical vvoc schema v3, public package exports, and spec package layout changes must be release-noted as compatibility-relevant changes.</Constraint>
   </Constraints>
   <Risks>
     <Risk>Shared workflows may reference custom roles not assigned on another machine, causing startup failures.</Risk>

README.md

@@ -35,6 +35,21 @@ Project scope writes only to `./.opencode/` and `./.vvoc/`. A normal `opencode`
 
 ---
 
+## 1.0 Stability Posture
+
+`vv-opencode` 1.0 marks the workflow as a daily-driver baseline: a hand-picked, curated OpenCode setup that packages the agent routing, managed skills, model-role indirection, safer editing, review loops, and release discipline used in real projects.
+
+The stable user-facing surface is intentionally practical:
+
+- `vvoc install` / `vvoc sync` / `vvoc launch` remain the primary setup and refresh path.
+- `vv-spec`, `vv-plan`, and `vv-execute` remain the canonical spec-to-code path for larger work.
+- `vv-review`, `vv-reflect`, and `vv-handoff` remain the auxiliary review, durable-learning, and session-continuity workflows.
+- The published package exports, CLI command names, canonical vvoc schema v3, and date-prefixed `.vvoc/specs/YYYY-MM-DD-<slug>/` artifact layout are treated as compatibility surfaces.
+
+The project still prefers conservative, explicit changes over hidden migration magic: user-owned config is not silently clobbered, invalid current config fails loudly, and breaking workflow or config changes must be documented in release notes.
+
+---
+
 ## Spec-to-Code Pipeline
 
 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.